DStaal

But with most open-source licenses - like the ones we're discussing - anyone can grant licenses to use or modify the code. (They just can't grant changed licenses.) So that doesn't solve the issue being discussed.

Air drag and heat are what fairings are for. But yeah, in general escaping the atmosphere isn't the biggest problem with getting to orbit. A straight-up launch to vacuum can be done for a lot less fuel than actually getting to orbit: It only takes a few hundred delta-v, really. But you need around 2,500 m/s of sideways delta-v to convert that to an orbit, instead of just falling back down. This mod attempts to get as much of that sideways delta-v as possible from gravity, without using fuel. Despite the flames shooting from the front of your craft, once you're a few kilometers up the air is fairly thin, so air drag is minimal. (Which you are seeing.) Short version: instead of an 'L' shaped launch, (to the top of the atmosphere, and then over), this mod attempts a curve to the edge of the atmosphere. Which means you stay in the atmosphere longer, but you're spending less fuel to get to where you're going. Time to apsis is how this mod works. If you install a mod to let you see what your current apsis is, this mod will hold that number fairly steady during the entire ascent. (Apsis/apoapsis being the 'highest' point of your current orbit - the point where you are furthest from the surface of the planet you are orbiting. So with the normal settings using this mod, if during your launch you cut the engines and coasted, it would take about 40s before you actually started to fall down. It basically continues to hold that until the highest point is your desired orbit altitude - though with most rockets there comes a point in the later stage of the launch where if you're keeping the engine on at all, it'll push the time to apsis out to later and later - that's what's happening during the coast: The apsis is already at your desired height, and the short bursts of thrust are just to keep it there because air drag is pulling it down.)

The problem with trying to moderate the contents in some way is that beyond the actively malicious (viri and such), it's hard to tell the difference between a mod that is doing something wanted and one that isn't - 'actively interfering' for instance could apply to the UKS suite of mods with regards to Extraplanetary Launchpads: The UKS mods redefine the build materials and disable all but a couple of the EL parts. But that's as designed, and they are intended to work together. Or you get the various Kopernicus mods that add extra planets - at what point does the fact that they don't play well together become 'actively interfering'? Does it really matter? Similar applies to placeholders - Some big, popular mods appear to have started with one or two parts. Would you have dumped them at the beginning because they didn't do what they were planning yet? How long do they have to 'get where they are going'? (And if they develop in a different way than the developer intended, is that a problem?) I'm in favor of the caveat emptor approach, in general: SpaceDock can certify that this won't be a virus, or try to destroy your computer. What it does to your game is up to you to research.

Gmail I know goes a bit beyond greylisting, and will actually block sudden spikes in email volume from a specific host. Give it a couple of days to learn the new normal, and things should work. Assuming that's the only problem, of course. NecroBones's reply points to there being other issues at work as well.

Just on the other side: My registration email came through just fine. (But I'm hosting my own mail, so I know what happens to all of it.)

Just to put into perspective, 25kg is the weight of a second-grader in the US. (An 8-year-old child.)

It's not uncommon for big mail hosts (Google...) to block or rate limit sites that are just set up and start sending mail. Even if they are fully correctly configured. Only thing you can do about that is to wait. Depending on what they are doing, sometimes the mail will eventually get through, and either way they'll start learning that you are a 'real' mail site and what your normal mail volume is.

Just wanted to say if you wanted the help of a Linux/BSD sysadmin with Perl skills (and who self-hosts his own mail and web server), I'm willing to help.

The only way I'd see opt-out as being acceptable would be if there were big, scary, prominent warnings everywhere to the users that this was not an official distribution channel for mods, and that it was 120% clear that any problems users had installing mods through such a service would likely not receive any support, and that in the case of problems they should uninstall, then reinstall. Given that CKAN wants to be an official distribution channel - or at least a trusted distribution channel - I don't think that's something that they want to be throwing in their users faces all the time, and therefore CKAN should stick to being polite and only distributing what they've been asked to distribute. (I do like the idea of Kwalitee-style checks for a version file and similar in the future - extra info provided to the mod users and makers is good. But that's info provided alongside the mod, not as part of the mod. It should be clear that such info/checks are from the site, not the mod's author.)

I'd use this page as the bookmark - easier to use most of the time: http://bobpalmer.github.io/UmbraSpaceIndustries/

The cargo pods don't seem to have been updated to the new resources. (Still have RocketParts as an option, for instance, but no Material Kits.) Any guidance on how much they hold if creating a patch? (Or am I missing something since I'm trying to figure this out at 1am. )

If you are updating the model anyway, can I make a suggestion to have an animated ladder fold down from the front? (I'm visualizing just one or two steps, that fold forward to just below the current rung, and stow against the underside of the cab. Just a bit of a 'beard' for the cab, but it'd make it a lot easier to grab on.)

Those wheels aren't attached correctly. You're clipping. (It's little tricky the first time attaching them - they attach the bottom half's walls, which at first glance looks like it's inside the part - but it's not, it's just between the exposed girder frame of the bottom half. There's an attachment point, make sure they are attached at it.)

I just added a pull request to the TakeCommand repository that integrates the 'every KerbalSeat' solution. Hopefully that'll get added in to the mod. Otherwise, here's a link to the config change.

I've put in a pull request making the change, to help push the idea along.

There's a config addition that's been proposed a couple of times in the TakeCommand thread that would automatically do this, by automatically adding the module to every KerbalSeat. It'd probably be a good idea to promote that solution.

I think your current size is fine, although I wouldn't mind a set of smaller trusses as well, one size down, for small probes and such. What I'd really like to see though is some pieces that have pressurized sections for Kerbals to move through, using Connected Living Spaces. Even just a hub that lets you pass through the 'round' sections.

Just an echo of that request. I've got a rover that just doesn't work with the standard wheels, but works fine with some small tracks, that I intended to use with AutoRove.

It's a very recent change - the last couple of days. And, unfortunately, it didn't make it into the change notes. There's a config file you can remove that does all the hiding, so removing it brings things back.

Sorry if I came off a bit forceful - GT is a great mod, and effortlessly launches rockets efficiently which Mechjeb had flipping end-over-end, and which I could only really launch with brute force. I would be disappointed if Overengineer1 didn't take up our suggestion, but I'd back off and let up about it if I think he understood it when he rejected it. I was trying to be clear and make the point about why we think it's a feature GT needs (and why it feels like the mod is a bit incomplete without it, to me at least), with the hope that Overengineer1 would understand our point of view better.

Even if they are Algae-based, it'd be like us eating pigs or cows - We're both mammals, but they aren't very similar in the end. And even if they aren't humanoid in their byproducts, you'd be able to find an algae that would be able to recycle for them, most likely. (Depending on the LS mod, we aren't even sure this is converting to CO2 or such.) In the end, it's all in how you take it.

Interesting mod and I like the idea, but I found myself hating the twitch-based gameplay it requires. I'm horrible at it (and my computer that barely handles KSP doesn't help...) and tend to avoid games that use it in general. Any chance for something like MechJeb that can lock onto a target and maintain that while I make observations? (I do find it odd that I can get a telescope for my back yard that can lock onto any star or planet in the sky automatically but we don't expect this to be able to do the same.) Even with a part or science cost.

I wouldn't expect launch data for a 100k launch to be learned into the launch data for an 80k launch. They are different launches, for different purposes. Really, most of the settings in this I'm fine with permuting to find the 'best' value - but altitude and inclination aren't about the 'best' value, they are where I want the ship to be at the end. Yeah, a 80k launch to 0 degree inclination is the most efficient launch, but if I needed that satellite in polar orbit at 250k, that launch didn't help me much. Let us lock the required values for those and have the mod find the most efficient launch for the requirements.

That was basically my thought. USI-LS's latest version just introduced a type of morale mechanic - 'homesickness'. It's a bit complex, in that there are two forms (away-from-Kerbin and been-in-this-bucket-too-long). The first tracks how long the Kerbal has been in space, and never resets. The second tracks how long they've been in their current vessel/ship, and resets with each ship. Both are affected by ship size/type of spaces/number of crew, etc. Currently USI-LS can't be completely closed loop either - you need a resources (fertilizer) that you can only get on Kerbin. (Though RoverDude has said that there will be a way to generate it in the future.) So my thought was that this system could be a closed loop (in that you can get anything you need to keep it running off-planet), suitable for initial exploration and colony setup before the bigger greenhouses get built/shipped in. The downside being that morale mechanic - You can run it forever, but your Kerbals won't be happy with you. (And what happens then is configurable.) I'd offer to help more, but I want to actually get through the science tree once before investing in playing with a life support mod. (Though I'm tracking the info so I can mentally compare how it would work, and tracking this mod as something I intend to use as part of that. I actually have installed Soylent and used the parts, but just as a 'ok, this base would need some supply something' cosmetic thing so far.)

The PackRat from the USI Exploration Pack is designed for that niche. Unfortunately, it doesn't fit in to the cargo bay either - but it can be stored in KAS storage (and assembled in place) so it's an option. The problem with the rover bay is that 2.5m is really slightly to small for a Kerbal+seat to fit, so nothing fits there. It looks nice, but it's the one part of this mod I never use. (Although, thinking about it... I should try designing an unmanned explorer rover to go in there - go run experiments remotely, then return to the 'base' rover and harvest the science.)