Search the Community

I dont care if you have or not, I'm a bit amazed by the fact some people take these ETA questions as an insult. People love this thing by just looking at the screenshots and want to play with it, rather now then tomorrow. That SHOULD be a great compliment but to you guys it's not somehow. Second, the guys here dont like to get ETA questions and are way too busy for anything KSP realted it seems, but do talk about this mod in other topics, what do you expect my friends? Feeling rushed/pushed by those comments is a choice, you can choose to ignore it and not let it get to ya, which I think is the more adult thing to do. I mean look at this topic, the last 2 pages I see only complaints and sneers at eachother.. How sad.\ Also, I gave you guys a possible solution: put the damn ETA in the OP allready!

Hi again, Tank. Now you know the math. Let's talk design. m0/m1 = (M0/M1)^(V/v) for equal delta-v. Quiz: Figure out which of these scenarios is preferable: Which produces enough delta-v for ship 2? A) m0/m1 < (M0/M1)^(V/v) m0/m1 > (M0/M1)^(V/v) Let's assume now that you have designed ship 1, and are happy its delta-v, but want a version with at least as much delta-v, changing only the engines and the amount of fuel. In KSP, most liquid fuel tanks have a full to dry mass ratio of 9. In the real world, the ratios depend on a lot of things, such as fuel type and cryogenic needs. I'm going to use 9 below like KSP, but you could use a variable or a different constant for a different tank mass ratio. m0 = rocket mass with full fuel m1 = rocket mass with no fuel Let's define a few more variables: mP = mass of the payload (minus the tanks): everything on the rocket that is not a fuel tank, fuel, or an engine mT = mass of the empty fuel tanks mE = mass of the engines empty rocket: m1 = mP + mT + mE full rocket: m0 = mP + 9*mT + mE Presumably, mP = MP: the payload is the same on ship 1 and ship 2. mE and ME are not the same: mE = 48-7S mass. ME = LV-909 mass, for example. mT and MT are also not the same: ship 2 will need a different number of fuel tanks I'm leaving the final bit of algebra to you: Solve for mT, the mass of the empty tanks, (or 9*mT, the full fuel tank mass), (or 8*mT, the fuel mass). Good luck!

I wonder if there's a video of this? http://life.time.com/culture/hubert-alyea-the-science-teacher-you-wish-you-had/#1 Princeton Professor Hubert Alyea apparently gave some very entertaining presentations in the 1950's on how nuclear reactions work. "Breeder" reactors that make more nuclear fuel than they consume (by transmuting Uranium into different radioactive elements) were well started on the R&D path, until the "greens" got that whole field of inquiry stopped off in the USA. Instead of recycling "spent" fuel we waste it by pulling it out and holding it in big pools of water and have a criminally wasteful on-again off-again plan to permanently discard it under Yucca Mountain (or not). It doesn't matter to the "greens" that there's no water for thousands of feet beneath that mountain, and the tunnels have been carved into a layer of solid rock. The material might somehow, possibly escape, sometime, maybe in a few thousand years. I'd like to think that long before then (if the facility ever gets used) that sanity would return to this and the nuclear material would be recovered for use. There already is a perfectly safe, non-explodable, type of nuclear reactor. The "pebble bed". The "pebbles" are about the size of softballs and have many small spheres of enriched uranium embedded in a graphite sphere. Around that sphere is a layer of ceramic and another layer of graphite - repeated to seven layers. There's not enough uranium in one sphere to be able to reach melting temperature and the shells are thick enough so that no matter how many are packed together, melting temperature cannot be reached. The heat transfer medium is Helium gas. If there should be a leak, it goes *up*. "But what about cracks?!" "There's no such thing as a nuclear pebble without cracks!". Yup. There's not. That's why the seven alternating layers. The odds of even one pebble getting a crack straight through all its layers to the center is very tiny. That's why pebble bed reactors have a system that pulls pebbles from the bottom, tests them for radiation leaks and if none is found the pebble goes back into the top of the reactor. If one is found to be leaking radiation (has one ever?) it's shunted to a shielded storage area. One of these reactors in Europe did have a problem with that system. IIRC a pebble got stuck but instead of calling in the people who knew what to do, the people on site decided they could fix it but instead damaged the pebble extraction system. Big stupid anti-nuke, media fueled broughaha followed and the reactor was shut down instead of being repaired. There was no radiation leak, nobody was in danger. The only people who should've had any problems with it were the ones who didn't follow the procedures they were told to. "This is your job. If something happens with anything not your job, you call in the people whose job it is." As for Fukushima, if you've seen some of the pre-tsunami file footage of the control room, you may have noted that it looks like it's technology from 40 years ago. That's because it *is* technology from 40 years ago. These plants were built then the anti-nukes have beset them ever since with lawsuits and regulations that have blocked any progress and technology updates. The damage caused by the tsunami and the results must've been like a ******* ****** to some of the "greens" so they could say "See? I told you it was a disaster in waiting!". They care more about being "right" in their wrongheadedness than actually improving people's lives. Some have wised up over the years, look up what the two guys who founded Greenpeace got into after they quit their own organization. Part of the problem Three Mile Island had was due to the even then aging technology. The control room had walls encrusted with controls, gauges and indicators. The lamp indicating the stuck open vent valve was on a different wall from where everyone was clustered, trying to figure out why stuffing more and more water into the thing wasn't working. When someone noticed the light and hit the manual override to force the valve closed, problem over but the reactor core was trashed. Only a small amount of radioactive steam escaped the buildings. The radioactive water was all contained. Historically, nuclear plants have taken so long to wend their way through the process of being allowed to be built that they're technically obsolete the day they first start generating electricity. The designs had to be "locked in" years before construction could start. Looking at San Onofre and its premature steam generator tube wear, I'd bet it was an issue some engineers were concerned about before the first shovel turned dirt on the site - but nothing could be done to change the design without delaying it for years. A modern system, as seen in many newer power plants and factories, puts everything in view of the operators on computer screens. If there's an alert, it doesn't depend on a tech making a circuit of a huge spread of gauges, the alert comes to the tech on his or her monitor. If TMI had had even the (what would now be primitive) best technology available at the time, someone sitting in front of a screen of green or amber text would've been flashed an alert about the stuck valve and there would have been no incident at all. Great idea but just try and get it added to an old nuclear power plant. Humans still have walk around and observe lots of separate and disparate things and make lots of notes. The 1977 TV series "Battlestar Galactica" likely had more advanced technology on its Galactica bridge set than TMI had in its control room. As an analogy, compare the original flight deck of the first Boeing 747 with the flight deck of a Boeing 787. The old nuclear plants are still at first 747 level when they should have received complete control upgrades at least once a decade or even closer together. Big airliners get upgrades, ships get upgrades, the Space Shuttles got upgrades. But not nuclear power plants. This "can't change a thing" craziness doesn't just affect nuclear power plants. In the 80's a company with a furnace they used to burn their waste to generate electricity for their plant needed to replace the refractory burner grates. The furnace manufacturer was long out of business. New more efficient burners could have been retrofitted but nope, wasn't allowed. either the system had to be restored to the same condition as it was when installed or the entire thing had to be replaced with an all new system. I don't how they came to talk to my father about their problem but he was able to take one of the old grates, made some forms from sheet metal and cast some new burner grates that passed muster with the regulators. Same shape, same or similar material, good to go. Here's some real big booms... Nice, safe, non-nuclear chemicals... I think somewhere there my be a video of the test where 25,000 tons of TNT were exploded - to see if the blast effects would be like those of an atomic bomb calculated to be equivalent.

I sit here on my overpriced Alienware, listening to people talk about their computers which are of equal quality, for a third of the cost.

The way I hear engineers talk (and I do work with a few), it's less twice as big and more that there MUST be a better way to do it.

Why do they oppose it? Because they're uneducated and stupid. I honestly don't know anyone knowledgeable of nuclear power technology that is against uranium fission. It's the safest, cleanest and most plentiful source we have which could become almost renewable with heavy employment of MOX and breeder technology one day. I cringe when people talk about burying nuclear waste. It's not waste, it's precious. How bad are we talking about? If it's total disaster like Chernobyl, that's impossible even with, for today's standards, old power plants because they have containment domes. Fukushima was not "really, really, really bad". It was very serious, and don't forget it was the tsunami, and don't forget thousands died because of the sea, nobody died because of the power plants. PR lies are a large problem, I agree, but remember that the worst disasters (Chernobyl, Mayak) happened in USSR which was a highly corrupt country. Fukushima happened in Japan, which is a traditionally fu*ked up society when it comes to being open about facts and exposing corruption. Whistleblowing and sincerity is just not a part of Japanese society as it is in the West. I'm sure that there would be much, much less PR problems if Fukushima had happened in France or USA. Granted, the PR problems with Fukushima were nothing compared to USSR in 1986. Remember TMI? The population was unharmed, yet the media and the society went all hawkeye on them, and it was in the 70s. The situation today is that when an ant farts in the vicinity of a Western nuclear power plant, the media goes crazy.

KMP is no longer in active development You can grab the latest dev version (which features many updates vs the 0.1.5.1 release) here. DMP is a successor project that offers full 0.23.5 support. ~~~~~~~~~~~~ v0.1.5.1 EXPERIMENTAL PRE-ALPHA Read the FAQ before using KMP! You have been warned... Download KMP client (v0.1.5.1) Download KMP server (v0.1.5.1) FAQ Known Issues Unofficial Server List Please note: This is an EXPERIMENTAL PRE-ALPHA release. KMP can and will do Bad Thingsâ„¢ including: Crashing Locking up Affecting non-KMP KSP sessions in some way Kraken attacks Assorted general weirdness Installation tutorial by RockyTV Changelog ###v0.1.5.1 TehGimp * Shrunk default safety-cylinder radius to 2000m * Tweaked rendezvous smoothing behaviour for better in-game performance * Optimized database performance during cleanup operations, which should address recent server slowdown/lag issues * Optimized server object serialization to increase overall performance * Fixed some bugs affecting the reliability of career-mode data (more fixes by trafalg & xterm91) * Fixed possible NREs when changing part opacity affecting game performance * Fixed server crash in some situations where a client doesn't disconnect cleanly * Fixed EVAs near KSC being sent to the server even when in safety bubble godarklight * Simplified KMP client<->plugin messaging Dazoe * Added option for alternative GUI skin * Ship control is now blocked while entering a chat message * Updated compilation scrips * Fixed server can crash with a poorly formed "/set" command Yilmas * Added "/lockship" server admin command for manually changing vessel privacy trafalg * Fixed various bugs causing loss of science points and career progress xterm91 * Fixed another bug causing loss of science points and career progress Need mods on your server? Read the included README and check out this tool. (Mildly outdated) FAQ What is KMP? KMP is a mod for v0.22 of Kerbal Space Program that adds a multiplayer game option. In a KMP game you can freely interact with other players and do all the Kerbally things you'd normally do in KSP, but with friends (or strangers) playing in the same universe, at the same time. Oh, and you can use (normal, on-rails) warp as much as you want. Surely you jest! Who's responsible for this hoax? No joke. It's a real multiplayer plugin and it even actually works (er... mostly). KMP builds on the already-amazing KerbalLiveFeed mod created by Alfred Lam/SodiumEyes, and KMP itself was created by me: Shaun Esau/TehGimp. KMP would not have been possible without the help of testers like Simon C. (CaptainCarpenter), nor without the numerous discoveries made and shared by KSP's incredibly smart & helpful modding community. Gameplay So I can race my friends to the Mun? Yes! Build space stations together? Totally! High-five during an EVA in orbit? Highly recommended! Build an outpost on Duna? Most definitely. Deorbit satellites with kinetic kill vehicles? I don't know why you'd want to, but yeah you can do that too... Have a drag-race on Eve? That one can be a little janky, but yeah you can! Trick my friend who's actually good at this game into doing all the hard stuff for me? I suppose... Build, fly, dream... together? That's a good way to put it--I should make that into a slogan or something. And I can use warp as much as I want, anytime I want? Yep--normal "on rails" warp is always available, though "physics warp" isn't. But... how? The big problem that immediately comes up when allowing players to use warp whenever they want to is that forcing everyone to go into warp is unpractical, and otherwise your local copy of the solar system wouldn't be synchronized with other players (so the planets and moons would be in very different positions relative to each other for different players). KMP gets around this by allowing players to play in multiple timeframes (or "subspaces") simultaneously. You can sync with any player that's "in the future" relative to you whenever it's convenient. That sounds complicated. Is it complicated? For gameplay purposes, at least, it's actually really simple! Need to go to warp for a few years to position that shiny new Jool probe? Go ahead! Want to build a new space station with your buddy afterward? Just sync up and you're good to go. That's it. What happens when I'm not in sync with someone else? You'll still be able to see those players and what they're doing in-game--you can chat, send screenshots, share designs, etc, but you won't be able to interact with any in-game vessels that those players control. Vessels from the past or future turn translucent so that you know that you won't be able to affect them. If the other player is in the past, KMP tries to predict where they'll be in the future and shows their ship at that location. Keep in mind, though, that since the ship is still being manipulated in the past, the predicted future location can rapidly change. If another ship has been manipulated in the future, you're effectively just watching a recording of events that have "already happened" play out. Won't everyone just be out of sync all the time? It depends on what people on a particular server are doing, but yes it's totally possible that everyone on a server might split into their own subspace, and that's A-OK! When you first connect to the game you're always placed in the "latest" subspace currently on the server, and if you ever want to directly interact with another player the most you'll have to do is click a button. Vessels that aren't under active control by another player and that haven't been touched in the "future" (relative to you) are all available. What happens when I disconnect? Will my vessels disappear? No! Your vessels are saved to the server's "universe" and will continue to be simulated whenever at least one player is connected to the server. Be sure to leave your ship in a stable orbit, or it may not be there when you come back! Your vessels cannot be controlled by other players unless you "unlock" them for public access, but keep in mind that other players can still crash into your vessels physically while you're absent. Can anyone just hop into my ship when I'm offline!? No! Your vessels are marked as "private" by default, which prevents other players from taking control of them or from docking with them. If you want to allow another player to dock with one of your vessels or to be able to take control of your vessel, just set your vessel to "public" status. Keep in mind, though, that whoever is in control of a vessel can set it as "private" to claim it for themselves!! Only mark ships "public" with players you trust. Is KMP massively multiplayer? Can I look forward to a solar system teeming with hundreds of players? No. KMP is solely intended to be used with relatively small servers hosting just a few players. The bandwidth and performance requirements that come with having more than a handful of other players are too high for most computers. Playing KMP How do I get started? Just download KMP and install it like any other mod. Then find a server (or create your own) and add it your connection list. For more details, see the README.txt included with the KMP download. I want more details or I still don't understand how this all works--can I see it in motion? I'm working on a video demo and will make it available as soon as possible, unless someone beats me to the punch. So what's the catch? There are quite a few. The most obvious ones are: KMP is currently held together by thumbtacks and Elmer's glue. As this is the first public version and it's in an EXPERIMENTAL PRE-ALPHA state, some features are missing or incomplete and there are bugs. Lots and lots of bugs. Big bugs, small bugs, minor bugs, and horrible bugs. Enough bugs that you (yes you) will get a chance to experience several first-hand. Check out the Known Issues list if you want to know what to expect. The space kraken has been awakened by the multiplayer hordes and may strike unexpectedly! There's no support for career-mode yet, only sandbox. Other mods are not "officially" supported in this first release. For now you (usually) must use stock parts only. Physics warp isn't available, and probably won't ever be. You can't pause of course, and you can't quick-load either (but you can quick-save and then copy the KMP save file to play a downloaded universe in single-player mode). In this first version only one player can control a single vessel at a time, but a future update will allow multiple players to share a ship. KMP can be demanding on your hardware. If your machine already struggles to run KSP, KMP will only make things worse. Kerbals in newly docked vessels tend to suffer from a temporary non-fatal bout of Double Head Syndrome. Some features are partially broken for Linux users. (Sorry! I'm an Ubuntu user myself, but I can't do much about bugs that are in Unity or KSP code...) And more! See the Known Issues list for details. What stuff doesn't work? See the Known Issues list for details. What new features are you already working on? KMP is a work in progress, and there are several features that I hope to add in the relatively near future, including: Bugfixes for Known Issues Career-mode support, possibly including a co-op career option Support for multiple players flying in a single vessel, either with one designated "pilot" player or shared controls Improved support for mods Visible custom flags from other players without having a custom flag pre-installed A server browser Server passwords Common Issues I was playing KMP and [insert calamity here] happened! What do I do? As a first step, always try fully restarting KSP and reconnecting to the KMP server--many bugs can be resolved by these quick steps. I can't get connected to a server. What's wrong? Contact the server's administrator for assistance. In this experimental release, exceptionally stubborn connection problems may require the server to be restarted. While building a Mun base I noticed that my friend's ships sometimes move a bit when they initially touch down. Is that normal? Yes. When a vessel touches down, KMP will update its exact position, which will correct any accumulated errors from near-surface flight. Additionally, incoming position/velocity updates from another active player can cause a landed vessel to appear to "dance" in place slightly. My friend was flying a space-plane in atmosphere when her ship seemed to disappear from my game. What happened? When a vessel is flying in an atmosphere outside the range that KSP simulates physics for it is immediately removed from the game (because KSP assumes the ship is going to crash anyway). Loading a vessel repeatedly causes major performance issues, so KMP will only add an in-atmo vessel to your game if it is within normal physics range. The other player's vessel is still tracked by the server and will always reappear in your game once it lands, breaks atmo, or comes back into physics range. You can also still view the other player's location from the Map View. When approaching or retreating from another active player, sometimes our relative velocity changes and/or our positions shift as the other vessel comes within about 2.5km range or so. Why does this happen? When other vessels that are controlled by active players are outside of visible range, KMP uses a positioning technique based on orbital data which is efficient in terms of performance, but which does not offer adequate accuracy for two players to successfully rendezvous and dock. To handle this, KMP switches to a relative positioning mode when two players enter rendezvous/docking range that provides sufficient accuracy for docking, but which also accumulates small positioning errors relative to the normal orbital positioning technique. As a result, when switching between normal orbital positioning and docking-mode positioning, vessels may shift position & velocity in order to account for these accumulated errors. Why does it look like I'm stuck in an Alfred Hitchcock movie sometimes when I initially approach another player in orbit? These odd position shifts are caused by KMP switching from "best guess positioning" orbital mode to rendezvous-mode "negotiated relative positioning". The time needed for the actual negotiation process varies with altitude over the current dominant body--the process happens very quickly in LKO, for example, but can take nearly a minute in an outer-Jool orbit. If two players get badly out of sync due to lag while in docking range, the negotiation process may take place more than once. I was trying to dock with another player but their position never seemed to settle down. What gives? Docking-mode positioning requires all players involved to be in very tight synchronization. If the total amount of lag between you and another player exceeds a certain threshold, KMP is forced to use alternate & far less accurate positioning methods. If your connection to the server is poor (e.g. if your ping exceeds 500ms), you may not be able to rendezvous with other active players (though docking with a ship that isn't controlled by another player should work fine). If you can't seem to get into range and you know your connection to the server normally works well, try returning to the space center and back to your vessel (which will force KMP to re-synchronize with the server). Unoccupied vessels generally behave more like normal single-player KSP, so if you still can't get into range, consider having one player wait in another ship or at the Tracking Station. Sometimes when I'm near another player in orbit I seem to lose significant amounts of thrust. What's causing that? Some thrust can be lost during docking-mode positioning, especially if you have a laggy connection to the server or a slow-running game. Note that this only occurs when other active players are in the region. This is a side-effect of the techniques used to ensure that both players see the same situation on screen with the accuracy needed for successful rendezvous and docking. I was rotating my vessel when I suddenly lost all rotational momentum. What happened? This most commonly happens when your game is commanded by the server to fast-forward in time slightly, in order to keep you in sync with other players. Why isn't KMP perfect? Kerbal Space Program is well designed to provide a smooth single-player game experience, but it is not (yet?) well adapted to the demands of multiplayer gaming. The way the universe is shifted around the player, the differing methods needed to accurately calculate ship position/velocity/rotation in different in-game circumstances, the need to accurately account for lag in the network connection, the various complications that result from timewarp, and many other obstacles all add to the challenge of creating a viable multiplayer experience. While I will endeavour to improve KMP further, it is very likely that many of the issues that exist now will not be easily solved. The Known Issues list outlines the bugs I am currently aware of that will likely be fixed (eventually). Servers How can I find a server? There's no server browser for now, though this may be an option eventually. For the moment the only way to find a server is to ask around (or start your own). If you don't know anyone who is willing to run a server, good places to ask around are Reddit and the KSP Forum. How do I set up my own server? See the README.txt file included with the KMP server download. Technical How performance-intensive is KMP? Will my machine that already barely runs KSP be able to keep up? While KMP does all it can to lessen the load, including doing as much work as possible outside the main KSP thread in order to take advantage of multicore processors, the demands of receiving physics information from other players and keeping your local game in sync are significant. You can expect a substantial FPS drop and even severe physics lag in some circumstances while playing KMP. If your machine struggles to run KSP, KMP probably won't work well for you. I've discovered a terrible bug! How do I report it? You can report bugs on GitHub. How does KMP work? I thought multiplayer was impossible! It's... complicated. If you have a specific development-oriented question and have watched this video, then please feel free to ask me questions about KMP's innards on Reddit (TehGimp666) or Twitter (@TehGimp). In a nutshell, KMP relies on your local game to do most of the heavy-lifting when it comes to simulating the universe, and updates information like a vessel's position & velocity based on what is happening in other players' games using a variety of situation-dependent methods. Why did you handle [problem X] with [dumb solution Y]? Given that I don't have much prior experience with multiplayer game programming, it's hard to say whether any particular clumsy element of KMP can be blamed on working around KSP's various idiosyncracies or just my own stupidity. Why can't I launch a vessel that includes mod parts? Is there any way around this? Vessels that include non-stock parts are prevented from launching because any other players that don't have those mod parts installed wouldn't be able to see your vessel (on top of other potential errors)! However, the restriction on mod parts was built with the knowledge that a later version of KMP will probably allow servers to specify a list of mandatory mods so that players would have optional access to their most-prized non-stock parts. If the players on a server can agree on a set of mods that they will all have installed, it is currently possible to override the mod part restriction when necessary using steps available in the README.txt file included with the KMP server. Can I use a mod that doesn't require using any non-stock parts? Generally you can, but this is not "officially" supported and mods may interact with KMP in unexpected ways including (potentially) crashing, having unexpected effects on gameplay, causing errors for other players, or even causing damage to a server's "universe". Unless you're eager to experiment, ask other players for information about whether a particular mod works well or not. Is the server "universe" simulated when there are no players connected? No! A future update may make this an optional feature, but in this release the universe is "paused" whenever all players are disconnected. Aren't you the guy that made the "Build Fly Dream" trailer? Yep How long did it take to develop KMP? I began work on KMP shortly after releasing the (now defunct) G_LockFlight mod, so about 5-6 months all told, though not all of this time was spent actively working on the project. There were many multi-week breaks in that period where I just didn't have enough spare time to work on KMP--for example, I didn't touch the project at all during July as I was busy getting married at the time. What's your next KSP project? Assuming I'm not stuck spending all my available free time supporting KMP at least, I do have some other KSP-related projects in the works that unfortunately I'm not willing to talk about just yet! ;-) Does KMP have anything to do with the L.O.G. multiplayer project? No--Since I rarely browse the KSP forums, I only became aware of the L.O.G. project myself in late September at a point where KMP was nearly ready for initial release. I wish the L.O.G. developers the best of luck with their project, and hope that my work with KMP will (if anything) ease some of their own efforts to some degree. By the same token, I welcome any input from the L.O.G. team that might improve KMP's gameplay and would be happy to collaborate with them if the opportunity arises. Source: Github License: GPL

What is this "outside" you talk about? I'm going to fetch my telescope. Or is it a new planet?

its somewhere in the middle i think. things like threading are good to get in early because it vastly effects the code structure. you could end up having to rewrite huge sections of code over again because it doesnt like your division of labor. x64 on the other hand is something that can and should be done in beta, before you start doing low level optimizations on your maths. when you implement this you all of the sudden have 2 architectures with different instruction extensions, each needing their own set of optimizations and bug fixes so that they behave the same. the compressed texture formats that i talk about in every single 'make the game faster' thread is a do it now kinda thing. why: x64 is a huge thing to implement(unless you linux), multithreading is a huge thing to implement. texture compression is a relatively tiny thing to implement (my game engine has that and its written in friggin lua! took me an afternoon) and self contained. it also will improve memory consumption enough where people wont be demanding x64 as much. later on, when you have x64, then you can double the resolution of ALL THE TEXTURES, and it will still use less ram than the current textures (and then double it again because you can address ram in droves). that doesnt really solve your physics bottleneck though. threading (or using the gpu) is how you fix that one. thats a big problem that is hard to solve. i expect that dev cycle to be no less than 4 months. it will be worth it when we get it though.

Wrong... 5thHorseman, your anecdotes makes sense only if you mean optimization before all the frills. Perfectly it would be optimize engine first before starting to add features, but sadly these days in development is features before everything else. And IMO KSP at the moment already has all the main features it needs (and what it does not have is, and can be covered with mods), but at this point what it really lacks is better performance. Its getting to a point where new features are becoming useless because of bad performance. We got docking, but we cant make space stations without major lags, there is talk about stock planetary resource system (you can use kethane mod at the moment) but you cannot make a decent planetary base without lags. In any direction KSP wants to expand (with features) it will hit the wall of max 300parts without lags. As it is for now, KSP only works well for building simple go to (and maybe return) ships. One exception is science and career mode(with parts cost eventually), as it actually forces you to minimize and gives additional meaning to "go-to ships". Also the more features you add the harder it becomes to replace/optimize the underlying engine.

My hangup is fear of trying missions with nothing more than IVA view. No map; no maneuver node. Maybe once in orbit I'll allow him to EVA to get some bearings. For all the "talk" about doing launches by going straight up instead of establishing orbit first I am strongly tempted to point out that if you figure out your launch window for straight up that it is MUCH easier from in IVA perspective to go straight up to the mun instead of first trying to pitch over for orbit and then figuring out when/how to burn from orbit to intercept. I haven't tried it hardly at all yet; but... it would be really interesting if SQUAD could include this sort of "feature" that would limit 3rd person perspective and limit map view and actually have an "impossible" difficulty that only supported IVA navigation. Maybe even have a 1st person EVA perspective.

I've heard people talk about putting parts in a game object, but I've never done it and still gotten parts that worked in KSP. Including air locks, although those are a bit hit or miss. Part of the problem with trying to mod this game is that everybody seems willing to share an opinion about the correct method except squad. I'm not aware of any tutorials done by squad personel. MY hirarchy for a pod with an airlock (but no IVA) is the pod mesh with a game object inside of it for the airlock. That's it. Just 2 items in the list. It may not be right, but I get a pod that kerbals can exit then re enter so it's not wrong either. Of course just cause it works for me doesn't mean that it will work for anyone else.

Obviously, you don't live here. "What time it is?" "Where you at?" "That ain't it." "Y'all cain't [sic] talk no English." Every day. Like the beating of the old man's heart, it drives one to madness! They /are/ uneducated. That's the state of being unaware of things, such as grammar and spelling. It's inappropriate to be offended by being considered uneducated. There's little or nothing you can do about it.

If your in career mode, purchase the parts inside the research center? I'll investigate this later. I highly recommend Hullcam VDS, as the developer is willing to support my mod otherwise talk to Romfarer for a key to exit the camera view.

Have you checked out the engine ignitor mod? I'm using it with Soyuz. Also, I've added Ioncross Crew Support to it. They're completely optional, but quite fun to use. Also, you could talk to the guy who made the ignitor mod for a better MFS integration. It should be able to tell hypergolic fuels from normals ones, and act accordingly. Also, ignitor number and max ignitions could be modified via MFS interface.

Not true. Lithium IS commonly made in large stars (ones much more massive than our own), since it's a common product in the fusion progression of larger stars and was one of the three elements created during the Big Bang. (Although "common" means something a bit different when you're talking about a universe whose visible matter is over 99% Hydrogen and Helium.) The catch is that stars large enough to create Lithium are also large enough to fuse it into something heavier (usually the Carbon-Nitrogen-Oxygen cycle, although really big stars go all the way up to Iron before stopping). Small stars that can't fuse Lithium into anything heavier CAN fuse it back down into Helium (Lithium-7 + a proton-> 2*Helium-4, referred to as "Lithium Burning"), so they deplete it VERY quickly. The temperature necessary to burn Lithium is actually LESS than what's needed for hydrogen fusion; an object can't fuse atomic hydrogen until its mass is about ~80 Jupiters, but Lithium Burning can happen above ~65 Jupiters, so the largest brown dwarfs will also be low in lithium. Side note: it really annoys us when people talk about Jupiter as a "star that failed", as if that factor of 80 in mass was only a tiny difference. When we talk about Brown Dwarfs, we're usually limiting ourselves to things heavier than ~13 Jupiters, because that's the point at which Deuterium can fuse (which is enough to heat them up intensely but not enough to be easily visible, since non-stars can't easily make more Deuterium). So don't confuse brown dwarfs with gas giants; the two have very different characteristics. Many Gas Giants are actually fairly poor in DETECTABLE lithium, because it bonds into solids that then sink into the planet's liquid layers; it's mid-sized brown dwarfs that tend to be rich in atomic lithium. So big stars won't have much detectable Lithium because they're consuming it as they make it, small stars (and large brown dwarfs) won't have much because they're burning it back down to Helium, gas giants often won't have much because it's bound into solids that sink down, and the brown dwarfs in between are the only things that keep it in atomic form. That's been suggested as one possible explanation, but it's definitely NOT the "working theory". Our Sun is rich in ALL metals (for astronomers, "metals" means "anything other than hydrogen or helium") because when the gas cloud our system eventually formed out of was coalescing, a massive star nearby went supernova and dumped some of its metals into our cloud. That shockwave probably also initiated our gravitational collapse, but the main upshot is that our system is much richer in metals than most of our neighbors. In most stars near us, about 0.5% of the mass comes from metals, while our own Sun is over 2% metals; it isn't even nearly large enough to create them itself through fusion, so they had to have come from an outside source, and no collision can possibly explain this sheer abundance of metals. That's not to say that a gas giant couldn't have collided with the Sun at some point, which might have left a measurable trace in the photosphere, but that would have been a drop in the bucket relative to the Sun's overall composition. The photosphere discrepancy, then, would imply that our Sun was initially rich in Lithium, just like it's rich in most other metals, but that the Lithium deep inside the star burned down to Helium while the lithium in the upper, non-fusing layers remained (until it sank down to the inner parts, which happens over the course of ~100 million years for most stars). Only the outermost areas, the ones without enough drag to sink the heavier elements down over ~5 billion years, would keep anything close to the original composition. Since those layers WOULD be the beneficiaries of any collisions, it's likely that the photosphere was enriched by a number of objects in the early days of the Solar System, which stretches out the timescale even further, but the sheer sizes involved mean that the elements we detect there now almost definitely were there from the start. To the earlier point, "hot jupiters" prevent what we'd think of as terrestrial planets, by tossing them all out of the system or into the star. A gas giant simply CAN'T form closer to a star than a rocky planet can, which is a small part of why Pluto got demoted. If one had slowly spiraled in from an outer orbit, it would have taken out all of the inner planets as it went. If a gas giant DID collide with our Sun at some point, it didn't spiral in slowly and didn't occupy any kind of close stable orbit; it had to have just dropped almost straight in, quickly enough that it didn't interact with much on the way down. During the early days of the Solar System, a lot of stuff got thrown around, but most of it would go outward, not inward. To actually hit the Sun, your interaction would have to bleed off all of the rotational kinetic energy in the primary interaction, and the chance of that happening is minute. Most of the stuff that got tossed around by interactions either escaped the system or ran into something else. (For instance, our own Moon was probably created when an object the size of Mars ran into Earth. We usually refer to that object as "Theia".) The sheer velocity involved would mean that you'd have to set up your intercept periapsis to be within the lower atmosphere before entering the SOI. Otherwise, you just wouldn't have enough time to steer it for an aerobrake during the intercept itself. Passing through that low at that speed is practically guaranteed to destroy your ship; they haven't implemented reentry heat yet, but the current drag model WILL cause your ship to rip itself apart if you hit the thick parts too fast. (Heck, I've had that happen on Kerbin just returning from Minmus!) The fact is, an aerobrake really only works when you're already close enough to the right velocity to skim the upper atmosphere without hitting the deeper parts. That's enough to move you from a pass-through interaction to a lopsided orbit that you can fix with rockets, but it's not enough to stop something moving at God's Own Speed. And that's what we're talking about here; when you're going from Kerbin to Duna you didn't start with much relative velocity (since they're going the same direction) and your transfer orbit kills most of the rest naturally. But intersecting a perpendicular orbit means your relative velocity is SQRT(2) times the orbital velocity, and a transfer in the plane of your own planet won't chop much off of that; it might kill of the relative speed from Kerbin, but it won't touch the huge velocity of the perpendicular object.

I think its a partial scam, Their just all talk and no trying to get it done. And YouTube vids as a selection program? WTF these people are dumb. No one who posts a video will have the training. I bet whoever they pic will die cause they dont have the proper education and stuff.

I say its a scam. It seems like their all talk and no do.

Gravity Turn Bob stared at the console. The Flight Surgeon was trying not to feel nervous with one of the original six of the Interplanetary Society at his back, watching him. Bob could have cared less. Right now he was just making sure his friend was OK. "Fifth stage separation, UNGH! and Forth stage engaged." Came Jeb's crackly voice. "Looks good Gene." someone said to Gene's right. "Roger EECOM. How's the turn look?" "Good, we're on the track within 0.6% so far. Got a delay on forth stage ignition from schedule, but we're on course. Flight, red light on number two." Gene stood straight and fingered his headphone mic as he stared at the screen. "Talk to me, what do we have?" "I'm reading turbo pump oscillations, 70% above nominal. Pressure reads good." "Switch to one and three, quench number two." "Roger, quenching two." "Something I need to know Gene?" Jeb said calmly over the link. "Nothing for you to worry about Jeb. Though you might want to talk to your old company when you get back. Looks like a failure in number two pump." "I'll go kick Ornie's butt when I get back." He chuckled Caldin leaned back from Telemetry and nodded to Gene with a serious look on his face. "We're reading under pressure on the stage three auxiliary booster number three. We're going to have to equalize. I think we're going to be under the arc on the main burn." Gene glanced sharply around his team, the first bead of sweat forming on his forehead. "How far under dv are we?" "It's timing, not dv. We won't have the high thrust long enough. I think we're going to have to light off the Munar descent engines for... ten seconds. That should keep the third stage good after the auxiliaries are away. Don't worry, we won't go into the reserve." After his eyes had locked with all of his team separately and got confirming nods of approval Gene fingered his mic again. "Jeb, when you light the third stage it's going to come up short. EECOM is adjusting the burn to keep them even, but it's going to wind up with you under on the orbit burn. Prep the Descent engines for ignition. Telemetry thinks ten seconds should be enough to keep you up so the main third stage can stabilize the orbit." "Roger Flight. Releasing safeties on Descent engines one through six. Coming up on Forth stage release." The next minute was tense. The display showed the jerk as the three, linked forth stage rockets separated and fell away, then the third stage main engine and it's powerful three auxiliaries lit up. The auxiliaries didn't last long, and soon they too were falling behind the rapidly ascending ship. All eyes locked on the main display, at least part of the time, while Jeb lit up the landing rockets to give him a bit of extra thrust before he hit Apoapsis. The numbers spun by and gradually the mission control team visibly relaxed as the velocity slid up into the green. "Cutting descent engines... and I read good on the burn. Twenty more seconds on main 3rd stage." "Telemetry confirms Munar one. Stand by for shutdown." "We're reading first data from the Scanners. Ground scan is negative on Kethane at present." This was a side issue right now but Gene nodded idly. Can't ignore things in the middle of a launch, even when you have an emergency. The seconds ticked by, then finally a sigh came from the room as the displays showed the ship's engines finally quiet. "And Munar One is in LKO. Thank's Gene, thought I was gonna be in trouble there for a minute!" "You're welcome Jeb. Stand by for prep for the Munar injection burn. Current plot reads... five minutes. You got a reprieve Jeb. Take five." The nervous laughter at least signaled some more confidence from the team, and Jeb certainly seemed on the ball. Maybe they could pull this off after all?

I disagree, 'Sol' is our sun, but 'Kerbol' (or however you want to call it) is Kerbin's sun. When we, earthlings, talk about THE sun, we mean Sol, the thing Earth orbits. When Kerbals talk about the sun, they mean theirs. Don't forget, in thousands of pieces of fiction that take place on other worlds characters or story tellers refer all the time to 'the sun', or mention things like "oh this world has 2 suns!", or "When our sun died, we migrated into space." In all those cases, they weren't talking about Sol. 'Sun' is a title we grant to any star when referring to it from the perspective of one of its planets.

I know there was talk about this a few weeks ago, but has anyone running the Linux x64 bit client been able to get Stretchy Tanks working in 0.21 or 0.22?

For a science system to be really integrated in a way that makes sense, there's a significant amount of underlying gameplay changes that need to occur on top of just the valuation of transmission/return of data. To cover what's been said in the thread so far, I'd like to see a system where 'data based' science (like thermometer readings) could be covered 100% with transmission, 'materials based' science only being fully researchable with a return, a balanced diminishing return that allows some additional value from multiple readings, and a relevancy system where the data gathered assists with directly relevant unlocks. But here are some of the underlying, more system-oriented changes I think really need to happen to let the above blossom into a solid long-term science setup: 1) Robots first. This means that incentives need to be balanced such that manned spaceflight has to have riskier mission planning and greater rewards than unmanned spaceflight, as well as an incentive to send the robots before the manned missions. Right now, using an unmanned vehicle is generally more prohibitive than using a manned vehicle because of the electricity burned off by the robo-brain (especially in career mode where solar panels/RTKs aren't immediately available), and it offers no benefit whatsoever - only the drawbacks of no crew reports, EVA reports, or surface samples. On top of simple things like manned pods being an unlockable after unmanned controls, there needs to be an introduction of overhead costs for manned vehicles; rations, life support, etc. Probes should be the primary tool for initial exploration because of their low cost to maintain and their only resource being easily and directly renewable (electricity). This can obviously play into talk of things like hydroponics etc, but that's out of scope of the discussion. 2) Modularity within modules. Within a given module could be several different 'slots' for sub-modules. These could be as broad as things like Hitchhiker containers holding four slots that can be filled with seats or storage (for supplies, etc) or direct improvements like a science module being improvable with better hardware, providing a new fount of science. This would allow for individual modules to continue being useful within a specific envelope with only a relatively small amount of effort required to upgrade them and gather more data. This would be especially pertinent when money is triggered - you could have an extremely expensive space telescope that gathers/transmits huge amounts of scientific data but it eventually loses value due to diminishing returns. Later, instead of launching a new space telescope when you research better optics, you launch a small manned mission to improve the existing telescope, allowing it to gather much more science at a small fraction of the cost of launching a new telescope. 3) Modules as containers, stuff as objects. The two ideas above require not just modules that can store objects beyond a simple meter (100/100 snacks) but modules that can store discrete objects within a shared storage space (60/100 storage, with 40 snacks, 1 mystery goo sample, 2 mun rocks). This could work for abstract 'data' as well, letting you store different results on a hard drive while keeping the results discrete. This would serve a couple different goals: this would be a vehicle for the greater overhead on manned spaceflight (you would have to budget weight and physical space for snacks, etc), a larger amount of hard drive space can be baked into robo-brains while a larger amount of physical storage can be baked into manned pods (pushing probes' role as exploratory data gatherers), and it could open the door for 'consumable' items to be loaded up, like emergency extra batteries for the life support systems. These three fundamental changes could allow for far deeper interactivity with science. For example: Science lab modules that can convert samples to data for transmission. These could have a varied efficiency based on quality and sub-modules slotted. It would allow for a sizable portion of the 'return' value to be gained remotely, but would also require a significant amount of infrastructure to run (a space station, rather than hot glued to an OKTO2). Research gathered from a specific celestial body can unlock sub-modules that can boost later research from the same body. You would be motivated to send a probe into orbit around Duna to gather data from orbit which would then be folded into 'extra research gained from Duna' sub-modules for the later manned mission. Stuff like 'mystery goo module' could be changed to simply a 'what does a sample look like module'. Mystery goo can be loaded up in your cargo and you can run it through tests (exposing it to the environment, setting it on fire, looking at it, etc). If you haul up a dozen goo, you can run a dozen tests. This could also play into things like seeing what happens when you release Eve water into Jool's atmosphere, creating an incentive to have a large network of science gathering rather than having a single manned vessel touch down and leave with 100% of the science (and 100% of the incentive to be there). Also, kind of unrelated, but a minor balance tweak that I'd like to see to make the rocketry side of research a bit more useful: when you switch up to bigger fuel tanks, there should be a weight savings due to economy of materials for the empty tank. Say, instead of a Jumbo-64 weighing 4 tons empty (which 64x T-100's would weigh), it could weigh 3, making it objectively better to use single bigger tanks over multiple smaller tanks but not so much that it would override staging/etc.

Quick question, I see rovers a lot in screenies and talk, do you guys build them or are they a mod or something? I'd just like to know cause' I'd rather play for a good while without mods until I really feel the need to add em'

Yeah, so all interactions with it are on the order of 1-2 kJ/mol. So maybe as little as 1/10th of water. At temperatures less than a third of terrestrial, that's quite normal. Keeping in mind that we have thermophiles at up to 400K with water as solvent, 90K for methane seems like an extreme range of a warm environment. So long as all of your organics is going to be non-polar and dipole-dipole interactions replace hydrogen bonds this is just the right temperature range. You are still thinking in terms of interactions you want at 300K+. For 90K, methane is just what you want. For starters, I'm not sure why you'd want to break C-H bonds. The building material we are considering is acetylene, which already has just one hydrogen bound to a carbon. So at worst, we need to break C-C bonds, which is considerably easier, especially if you start with a triple bond there. But ok, I'll bite. Lets talk about the C-H bond. You insist that it's necessary to be able to break it for biosynthesis. 435kJ/mol is 4.5eV per bond. At 300K you are going to get 0.013 eV per C-H bond from thermal excitation. At 90K you'll have 0.0039eV. So to break the C-H bond at 90K, you have to supply 4.496 eV of energy, and at 300K you have to supply 4.487 eV. Are you seeing a lot of difference? Because I don't. Let me put it another way. Temperature at which average energy will exceed 4.5eV per bond is going to be over 100,000K. So it make absolutely no difference if you compare that to 90K or 300K. You have to do something creative with it if you want to break the bond. So it's your turn. Why don't you go into details of how this C-H bond is broken at 300K and try to explain what it is that prevents it from happening at 90K.

Methane is by all means quite similar to a noble gas and behaves like an ideal gas. Methane molecule behaves like a tiny ball. Its tetrahedral structure ensures the force vectors arising from the small electronegativity differential are nullified. I do not see it as CH4, is see it as a ball with a name CH4 written on it. I am quite aware of the biochemical requirements, thank you. What you don't realize is that the energy to break apart one C-H bond in methane is 435 kJ mol-1. I'd like to see that in a cryogenic environment, and please, no enzyme talk. It's ridiculous. If you can give any, even remotely solid, hypothetical mechanism for that, I would consider it as a possibility. Until then, I see your arguments as "it's space and anything can happen in space because it's not Earth" and therefore you can proceed working on liquid helium life, too. Biological membranes work using a combination of hydrophobic bonds (pseudoforces arising from the tendence of surrounding water to lower its energy state by binding together and excluding other nonpolar stuff) and hydrogen bonds from the polar parts of the lipid molecules. Hydrogen bonds are a special case of Keesom forces (dipole-dipole) so I'm not sure where are you getting at with this question. Can you clarify it?