Search the Community

Been playing a very long time, ran into a problem yesterday... Upon an EVA on Minmus I attempted to do the routine science experiments. All equipment in the craft worked well but when I right clicked Valentina and clicked on surface sample no dialog appeared and the button disappeared entirely. I tried to do my EVA report and got the same result and now the only button left is Plant flag and I can't get the others to return... I really need help on this one.. Thanks in advance!

This is an fairly simple issue, labs can only store 500 science, with high level scientists they will fill up the 500 in less than an month. To reduce number of interupts during long interplanetary missions I thought to increase the science storage to 2000, this would let the lab run longer. However I have no idea how to work with module manager, even if this should be an very simple script. Any guides or tips or samples?

Copenhagen Suborbitals put up a nice vid about how regenerative cooling works, featuring a cross-section of a failed engine. They also talk about laminar flow cooling and water hammer effect.

Problem is that the science is new and it will not load , states that the science lab already got this. Last landing i was on a new spot so im sure its not "old" data. Hooked up another lab, and it loaded all the unusable data. What is wrong ?

Okay, so my first station was in orbit about 85 km above Kerbin. Kerbin Station Alpha is pretty basic -- two Hitchhikers and a cupola, with a pair of Clamp-o-tron Jr., some batteries, and solar panels to charge the batteries. On a whim, the commander went EVA and took an EVA report, which produced some useful science (because it was "above Kerbin's shores" or some such -- in other words, I was low enough for biomes on Kerbin to matter, which is a science realm I haven't touched). I'd love to get this science, since it'll be nearly free (just add some instruments to modules already planned for addition to this station -- barometers, thermometers, goo cannisters, etc., cheap and easy). However, there arises an issue, and will arise another: initially, how do I get the data Lufrid generated down to Kerbin so R&D can do something with it? The station has a high-gain antenna on one of the Hitchhiker modules, but it's not the one with the working hatch (the cupola and other Hitchhiker hatches are blocked by solar panels and docking port, respectively), and when I tried to immediately transmit the EVA report I was informed there was "no antenna within reach" or something of the sort -- and when Lufrid had re-boarded the station core and transferred to the module with the antenna, I couldn't find the EVA report to transmit. Longer term, once I can reliably transmit my science from Kerbin Station Alpha, have instruments, and have a scientist aboard, will that scientist be able to reset experiments from inside the station, or will he/she have to EVA (presumably within a certain distance of the experiment) to do so?

So, I wanted to make an 'all in one' tug/explorer (vanilla parts) to export almost all of the Kerbol system. Criteria was that as much of the ship as possible should be reusable at each stop, and it can refuel itself along the way. My plan was to have three main components: a driller (for refueling), a science lander, and a tug to transport the other two components. The driller was pretty simple, with a 4500 ore capacity: Note the large docking port atop, that will mate to the 'back' of the tug. The harder part was building a lander. I started a lander that would handle MOST of the standard planets (Mun, Eeloo, etc) a single stage land/takeoff that would have about 3000+ dV. Added chutes and drogues for Duna and Laythe. For Duna and Laythe, I added a removable inflatable heat shield, connected with a docking port so I could add or remove it as the mission required via a docking port: Experimenting with the inflatable shield was VERY interesting. A few lessons: If you inflate it and it touches an atmosphere, you can't deflate and re-use it. Which means I'd need to bring one for Duna and one for Laythe. When you deflate it, it *VIOLENTLY* explodes. So I separated it as much as I could, and experimented to make sure after the peak of re-entry heat, I could turn the ship prograde, drop the shield, and then flip back retrograde before finishing the landing sequence (in some cases just turning sideways and firing the engines to get the heck away from this giant bomb I'm carrying). Otherwise, the air resistance forces the shield back into the craft, with another BIG BOOM. So, that being said, my tests with Laythe still didn't work because of the high dV needed to push through the atmosphere. So, I added another optional stage I could also add with a docking port: It's super ugly, and the lower engines gimbal way more than they should, making it a difficult craft to control. But I get an extra 1630 dV from the lower stage, coupled with 3670 on the upper stage (if I use the drop tanks, but a bit less otherwise), gives me about 5300+ dV total, enough to land and take off from Laythe and Tylo. Note that I have to cut the fuel cross-feed (otherwise it robs the upper tanks first) and the stage cutover is a manual redocking/staging sequence, but not too awful. So, now I have all the planets covered, except for Eve, of course. So, here is the assembled tug, powered by a dozen nuke engines: Note the two 'extra' sections being carried: - Fuel/Engine set for Tylo - Thermal balloon for Duna - Another set of both for Laythe And, of course, a science lab. Fully assembled and fueled, she has about 5000dV. Getting ready to run the full system test!

So I was wondering, if you had a time machine and could go back in time or bring someone back from the past, what would be the current science topic or discovery you would enjoy explaining to a past scientist, and why? Maybe it's providing the confirmation that his/her theory was correct to a scientist that never lived to prove their conjectures, or maybe you would like to show someone how far off from the truth they were, etc. Special points if you re-enact the conversation with the old scientist.

Just returned to the game after a long break, decided to start a new career with a few mods (mostly engineer and contract configurator). I habitually take a scientist on most missions as their description says they boost science return on the vessel they are in. As an experiment I decided to work out how much extra science it was making from my typical Mun mission with and without a scientist. To my surprise I found that my level 1 scientist (its early game OK! ) was not boosting the science return of my vessels by the advertised amount (5%) and the science return was the same no matter my crew composition. I have already tried the same test in a new un-modded save with the same result. Have I misunderstood the scientist description text or am I doing something wrong? Cheers.

RELEASE 2.2.0 (alpha) Plugin is now compatible with KSP 1.2, but I haven't had time to thoroughly test. Therefore I've chosen not to push the release to SpaceDock/CKAN until it's confirmed this new version is fine (I would be very grateful for any help!). See new version link below. RoverScience is a KSP plugin that attempts to add more interactive functionality to the science system FOR rovers. You drive rovers to search for science spots which you may then decide to investigate and analyze for science gain. Rover Brain parts made by @akron Wonderful tutorial/showcase video by youtuber KottabosGames; thank you! There is one discrepancy, however: you do not get more science the farther away you are from the landing spot - you only generate science spots much quicker. What does give you more science (potentially) is scanning for science spots farther away from the rover (this is what the scan range is for): see here for the boost to science potential with distance from the rover. Steps are pretty simple: Quick Instructions [1] Build your rover and attach the appropriate Rover Brain and ensure it is pointing "forward". As long as it is pointing "forward" it can be placed anywhere on your rover. This forward orientation is not critical to the functioning of RoverScience, but it will provide you with a convenient "Control From Here" for driving the rover correctly forward. [2] Right-click on the Rover Brain in-flight and click "Activate Rover Terminal". [3] This console will update you with information regarding the Rover Brain. Drive and explore around to search for a science spot. [4] After driving for awhile, you may detect a potential science spot. This will be shown as a large red transparent sphere waypoint. Drive towards the waypoint to further investigate. [5] Drive into the marker and it will turn green. You may now analyze for science, but before you do consider the potential science. Every science spot analysis will increase future science loss; be wise with which spots you wish to analyze, and which to abandon. At any point you may click on "Reset Science Spot" to begin search for another spot. [6] This is the upgrade menu. "Current" shows you what value an upgrade currently has. "Next" will show you the value if you increase the level. "Cost" is how much you will spend in science to upgrade. "UP" is the button to upgrade. An explanation of each of the upgrades is given further below. All upgrades are permanent and work across all rovers! Click HERE for information on RoverScience Upgrades Notes: Firstly, RoverScience will not function unless the Rover Terminal is opened. This is done through the right-click menu of the Rover Brain part. RoverScience will only search for science spots if your vessel has at least one wheel, and that it is in contact with the ground. Upon landing, your rover will establish a landing spot. Driving farther away from where you originally landed will increase chances of finding a science spot. Science spots detected far away from the rover will have a bonus multiplier added to them. You are rewarded for exploring and reaching far destinations. Bear in mind that a 50% increase to 10 is only 15 -> carefully consider whether the potential (or the prediction) is worth it. Each analysis you commit to will slowly degrade a rover's return of science. For the first 2 analyses you'll get normal values, and anything past that will slowly degrade the amount of science you get back. Soak up those high potentials as much as possible! CTRL + R + S will open the RoverScience menu. DOWNLOAD FOR KSP 1.2.1 (or SpaceDock link) (or CKAN) This mod includes version checking using MiniAVC. If you opt-in, it will use the internet to check whether there is a new version available. Data is only read from the internet and no personal information is sent. For a more comprehensive version checking experience, please download the KSP-AVC Plugin ___________________________________________ SpaceDock Link README Everything should be running fine, but if there any issues please post here or, even better, on the RoverScience GitHub. Known Issues: 1. Two rovers with Rover Brains that are within physics range will throw Null References and will break RoverScience. Much thanks to the community of KSP modders, who have been very patient, very kind and very helpful. This is my first major C# project and I'm still learning. The code may be messy in some places and I apologize. But nothing will ever describe my gratitude to those who helped - particularly malkuth, whose inbox I have no doubt spammed with questions. Rockstar04 for loyal testing for much of the development. And anyone else who I might have forgotten (sorry)! Some more thanks: - etmoonshade - udk_lethal_dose - akron for Rover Brain parts - modelling and texturing - Nat Sum for rock models! This is a wonderful community, and I thank you all once again. This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

So umm, a couple months ago I was lazy and used mods like Kerbal Engineer for data readings. Soon I became interested in collecting those data values myself. Soooo I headed to the cheat sheat in the KSP wiki. I learn’t ‘The Rocket Equation’ quite easily and then moved onto TWR. But whenever I plugged in the numbers it would turn out wrong. So I spent hourrs trying to solve this problem with no results. Here is the formula off the wiki: Where Ft is thrust m is mass g is the gravitational acceleration I’m also using a scientific calculator for these calculations. Any help would be appreciated whatsoever!!!

A note to start off: This is quite a long post with stuff that might be boring for some of you. If you just want to know the conclusion, skip to the end. So this all started while I was reading through this thread in the game-play questions. Being a bit of a turbohead myself, I figured I could help out at least a little bit with the aerodynamic efficiency of the propellers, even if electric engine types weren’t really my thing. As I read through, I encountered @Geschosskopf who believed from his extensive experience with Kraken and Ladder drives, as well as his (excellent as you will find out) spidey senses for potato physics that stock propellers must exploit physics somehow, his hypothesis being that they were taking advantage of some kind of artifact of the game’s collision physics that ignored Newton's 2nd and 3rd laws. The idea being that the propeller was dragging the plane along without “feeling” the plane. The very good reasons for this idea are summed up in the following argument. “How many RTGs do you put on a shaft? 4-6 at most, maybe less? Each RTG makes 0.8 EC/sec. The accepted conversion rate to real units is 1 EC = 1 kJ, so 1 EC/sec = 1 kW ~ 1 hp. Thus, you're only putting 3.2-4.8 hp into the shaft, which is the about what you get from a small lawnmower engine. How are you even going to taxi, let alone fly, a multi-ton aircraft with that little power?” - Geschosskopf I knew ladder drives and kraken drives took advantage of some strange physics, but I couldn’t wrap my mind around the idea that the physics of collisions between basic craft (like the propeller shaft and the plane) could be messing with things, because that would imply some very wonky effects would be seen any time two crafts were in contact. That being said, I may have been a bit biased since I regularly work on stock turboshaft helicopters. We struck up a lively debate in a private chat, which took place over the course of 3 days. His arguments usually went into the workings of the game, looking at how it (probably) models collision, trying to insure that the collision meshes two parts on different vessels are not clipping into each-other, and moving them a bit if they are. Meanwhile mine usually stayed more on the player side of things, using thought experiments such as a caged jet (this will be followed up on later) to show why it didn't make sense that the propeller was pulling the plane in ignorance of Newton's 2nd and 3rd laws. Eventually I decided to actually run a few KSP experiments to determine the viability of the wonky physics idea, and otherwise determine what was going on. The first experiment was with a Mallard carrying an orange tank. The Mallard had the orange tank inside the cargo bay mounted on a decoupler, with cubic struts and I-beams positioned around it so as to act as a cradle for the orange tank, preventing it from moving when decoupled. The configuration can be seen here. The idea being that, if collision physics work properly, the plane should take off at exactly the same speed if the orange tank remains attached to the plane as if I decouple the orange tank and let the cradle of cubic struts keep it from moving. If the collision physics are wonky like Geschosskopf theorized, then the plane should take off at a lower speed when the orange tank is decoupled, because the game will think the plane is only lifting itself, and will only teleport the tank along to prevent clipping. I made the first run with the orange tank still directly attached to the aircraft. I was a little late with the screenshot, but it took off at 76.1m/s. I made the second run with the orange tank decoupled and held in the cradle. I made this screenshot on-time to see the takeoff once again at 76.1m/s. Exactly the same as the previous takeoff. Sequential trials produced almost identical results, thus appearing to imply that the collision physics worked properly, obeying Newton’s 2nd and 3rd laws. But I wanted to be extra sure, so I devised a second experiment. The second experiment I called the “Caged Jet Experiment”. The idea was to simulate the pushing of a stock propeller on an airframe using a jet engine. Just in the same way a prop-shaft is restrained to the airframe of a stock plane or helicopter by a bearing, a jet engine would be restrained to the airframe of a Mallard by a “cage” once again composed of cubic struts. The idea being that a jet engine would stand in for a propeller shaft. If the collision effects ignore Newton’s 2nd and 3rd laws in the way Geoschosskopf theorized, then a jet held in a cage should make the plane move much faster than one directly attached to the plane, because the jet engine doesn’t realize that it is pushing the big heavy plane. I didn’t take many pictures of this one because I didn’t have an autopilot installed to allow me to hold a certain altitude precisely, so as to be able to quantitatively measure the performance of the plane. However I testify that it performed nearly if not exactly the same when the engines were decoupled and trapped in the cages as when they were still directly connected to the plane. The only difference was that with the decoupled engines, I could not reduce throttle for landing afterwards. Good thing the Mallard was a seaplane! Another experiment I proposed, but did not perform, was to attach a 5 ton trailer to a 3 ton rover using a stock pin-in-hole joint. If the collision physics work correctly, the setup should behave exactly like what it is. A rover pulling a heavy trailer, with all the associated performance losses. However if the collision physics are wonky, the rover should still have the same performance as if it were driving on its own, and pull the trailer along as if it is nothing. I’m guessing the people I see on here building semi trucks every now and then that a truck most definitely is affected by carrying a trailer behind it. So, the collision physics didn’t seem to be the root of the problem, so another idea came up. That was that KSP didn’t know how to properly get the thrust of a stock propeller, however this was quickly disproved by the point that a propeller is quite literally a number of wings moving a circle. KSP doesn’t have to do anything to find the thrust of a propeller or lift of a rotor that it doesn’t have to do to find the lift of a plane going into a slip-turn. So then there was my hypothesis that the 1EC = 1kJ standard was incorrect. I devised an experiment to try to prove or disprove this. So how it went in my head was that I would measure the torque output of a reaction wheel in relation to the angular velocity. Using these values I could determine the power output by the equation power = torque x angular velocity (P = τω). By comparing this to the electricity drawn (EC/s) by the reaction wheel, I could find the energy content of a unit of electricity. For the experiment I created a kOS script which can read the angular velocity, and use that to determine various other statistics. I also created a special vessel with which to perform the experiment There is a probe core, a fuel tank, a reaction wheel (the 0.625m type, which has a constant electric charge draw of 0.25 EC/s), and two spider engines on the sides directed so as to create torque. The engines are a known constant source of torque, calculated to be 7740 newton-meters. So what the script does is activate the engines, and then take a reading of the angular velocity and labels it Ang_vel0 at a time desginated T0. It then waits a short period, and measures the angular velocity and labels it Ang_vel1 and takes the time as T1. It can now calculate the angular acceleration as (Ang_Vel1 - Ang_Vel0)/(T1 - T0). It can then calculate the moment of inertia of the craft in the roll axis using α = τ/I => I = τ/α. Moment of Inertia = Torque / Angular Acceleration Note that I use the infinite propellant cheat during this experiment to make sure the moment of inertia doesn't change as the engines fire. Anyways, so the script shuts off the engines again, since it needs no disturbances for the next part of the experiment. I use timewarp to bring the spin back to a halt, so as to have no influence from the previous bit that determined the moment of inertia. The script now locks the ship's roll control to full clockwise (would work counterclockwise just as well, that's just what I picked), and uses the same procedure of finding angular acceleration using = (Ang_Vel1 - Ang_Vel0)/(T1 - T0). It displays this value as well as the angular velocity** Since it now already knows the moment of inertia, it runs it the other way to find what torque the reaction wheel is producing. τ = I*α It displays this value** Now with the torque and the angular velocity, it can calculate power via P = τ*ω It displays this value** **All these are updated over time, allowing changes to be observed By plugging all the displayed values into a spreadsheet, I was able to create charts displaying various items such as torque curves. To my intrigue, at near-zero angular velocity, the 1EC = 1kJ conversion rate was true (so in the graph I put EC/s as W for watts), but as angular velocity increased, the reaction wheel appeared to be developing more and more power from the same constant power input. I and probably a lot of people here knew reaction wheels were broken due to lack of conservation of momentum, but this demonstrates just how badly they are broken. At just 9 radians per second, the reaction wheel is multiplying the power input by a factor of 150. Thus you can give an electric plane spitfire performance with the electric power equivalent of dinky little lawnmower. I have yet to perform the experiment up higher angular velocities, however it would be interesting to see how the trends continue. I want to add some more tests into the experiment as, now that I think about it, I'm wondering if torque is actually constant, and the apparent change is due to the spider engines stretching away from the tank due to centrifugal forces, thus changing the moment of inertia slightly. Perhaps I can devise a method of testing that does not require any off-axis parts.* Current conclusion: Stock propellers in of themselves are not exploitative, however electric props take advantage of broken reaction wheel physics to generate power a couple orders of magnitude greater than what is put in! So neither Geschosskopf nor I were entirely correct! *Update: After further testing using a reaction wheel and a tank with no radial engines, I have found that the torque output of reaction wheels is constant. Using this I plan to calculate the MOI of numerous parts, which could be useful for the construction of mechanical contraptions. Thanks for reading! Also thank you Geschosskopf for the fun debate and the push to question the workings of the game. This all was quite interesting to work out. For anyone interested in examining the script I used you can find it below. The order of the display of values and their labels have been modified slightly to be more user-friendly, but all the math is the same. Not that the variable labeled "Torque" is used twice in the script. In the first section it is a fixed value, designating the torque from the two engines. In the second section it is overwritten and is the calculated torque output of the reaction wheel.

Hello, This is the release section for my latest and most developed to date mod, Kerbin's KSP overhaul. what it adds: a more challenging career mode with less science at the begining new replacement resources more labs and most importantly MOAR SCIENCE! what makes this different: normaly, career tech tree mods require community tech tree however Kerbins KSP overhaul like my other mod 64x overhaul require only Module Manager DOWNLOAD https://spacedock.info/mod/1611/Kerbins KSP overhaul hope you enjoy!!!!!! coming soon: PARTS! thats all from me, the rest is all down to your imagination (with the career limits of course!)

hello, welcome to my KSP overhaul development thread, my second mod designed for KSP this mod aims to add: more fun buttons to press within the IVA... more fun resources to play around with! and a better career system? https://discord.gg/juenMcX to do list: Resource utilisation... IVA modded IVA Licence: All rights reserved DOWNLOAD! https://spacedock.info/mod/1611/Kerbins KSP overhaul dependances: Module Manager update - (15/12/17) Figured out science defs, thanks @DeltaDizzy! Screenshots to come on monday so are new experiments, new parts (maybe) IVAs (more than likely), certainly bugfixed expect releases on monday!

Hello, I recently had to reinstall all my mods because I hadn't played since before 1.3's release. I didn't have much trouble updating all the relevant mods and getting them reinstalled and my game now opens and works correctly. However, the only issue I have is that when I tried to load up one of the specific ships I made earlier, it fails and says that it can't be loaded because it requires a missing component 'scienceModuleAdvanced'. Does anyone know what mod this component might be from as I may have missed one of my mods while reinstalling or something. Thanks Image of error

Using ModuleManager, I want to edit the tech tree or all the parts (including modded parts) to make everything be unlocked from the start of a career playthrough. This is to make a contract-focused mode that is basically the opposite of science mode

Well, basically this is the question. After complete the tech tree, you still play in the save or you just stop? And why?

Question: When lightning strikes afar off, we see the light almost instantly and the sound waves race at different speeds to us with the shortest wavelengths first (crackle sound) and then the rest in a rolling sound as each frequency reaches the ear one after another with lower and lower pitch until the largest wavelength finally finishes the race. This makes sense because Speed=Distance/Time. The shortest wavelength travels less distance to the ear because it’s journey is closer to a straight line. The largest wavelength travels more distance because it must ascend and descend a good distance before making much forward motion. If the electro-magnetic spectrum includes large wavelength radio waves, medium wavelength visible light, and very short wavelength gamma rays, then why does it not follow that light must travel at varying speeds and not constant. If gamma rays and radio waves both were moving at 186,000mi/sec wouldn’t the radio waves be slower than the gamma rays since Speed=Distance/Time. The radio waves takes a longer journey than the gamma ray because the wavelengths are the photons ascending and descending and not moving purely forward at 186,000mi/sec. If we do observe all of the spectrum being constant at the same speed, wouldn’t that mean that radio waves move faster than gamma rays to make up for the greater ascension and descension? If all light is constant in speed then isn’t all light moving faster than the speed of light because 186,000mi/s (I assume) is the speed of light from point A to point B in a straight line in a vacuum? Light must be traveling faster than that figure to make up the extra distance, right?

Science checklist with all biomes and situations Why another one? There have been many such lists made before, but I didn't really like any of them. Either they were too detailed (separate checkboxes for every single experiment, when you usually perform many if not all of them at once), or not detailed enough (no provision for all the biome-specific science in every possible vessel situation). How is this one better? It provides checkboxes for all combinations of biome and situation, for all biomes of all stock planets and moons, so you won't forget to do your "Flying Low" science over Eve's Peaks. It includes the "splashed down" situation where possible, and also all of KSC's special biomes. All this in merely 4 pages (plus the title page). It even shows the altitude to achieve each situation of "space high", "space low", "flying high" and "flying low" (where applicable), and which of the stock experiments are biome-specific in each situation. I also added some coordinates for some hard-to-find combinations of biomes, such as getting "splashed down" on Kerbin's mountains or Eve's peaks. Downloads Without further ado, here are the downloads: PDF document for printing LibreOffice/OpenOffice document if you want to edit something Or some images to look at if you prefer: Hope it helps! Go max out your science! Suggestions for improvement welcome! [edit] Fixed images. Note that since the 1.2 biome changes, the landing locations indicated are not nearly as complete anymore biome-wise.

This is small, just a little idea I had: the scientific classification of Kerbals. Domain Eukarya- cells have nuclei Kingdom Animalia- moves, eats Phylum Chordata- Has a spinal chord Class Virentia- Latin for "green things"; a cross between Mammals and plants Order Primates- walks upright Family Kerbalidae- Kerbal-Like Genus Kerbo- Kerbalized version of Homo Species hebes- Latin word suggesting at Kerbals' not-all-that-intelligent-ness. Thus concludes the scientific classification of Kerbo hebes.

Hi, I'm having a KSP freeze/crash when performing a science experiment where the Science report GUI doesn't even get to appear. The KSP screen freezes and I get the windows 'processing/waiting' circular mouse icon. The experiment has been both a stock and moded item, so I don't think the part is the issue. I've checked both the log files and had the console open when replicating the issue to try and get information, but the game freezes before anything is written to those possible data sources so I'm left with no direction to track the issue. I've tried to leave KSP overnight in that frozen state and it never has come back, so it's stuck doing 'something'. I've removed a few mods related to science (CrowdSourceScience & [X]Science) but the issue still persists, but is at times random. When I take the same vessel to a separate game using the same install, there are no issues at all and the Science GUI appears as expected. So I'm not sure what to use to get some additional information. Is there are any other tools that can help isolate what might be causing this issue? Log file -> https://ufile.io/s81l0 Mod list below in case it's an obvious conflict someone knows about.

A continuation of the original DSD Mobile Labs. Updated and re-balanced to 1.2. I have contacted the original author (@JDCollie) who has been kind enough to endorse a re-release under the terms of the original licence. All credit for the models and the initial mod go to JDCollie. This is a continuation of that work. Like JDCollie, I felt that the current science lab is lacking in a few areas. After trawling around for a decent modded science lab, I couldn't find anything but DSD, which was woefully unbalanced for use in 1.2. So I've rebalanced it and updated the configs to have more specialised roles. It increases the rate of science generation in labs, balanced by tweaking yields and running costs. The science rates are faster than stock, but hopefully not too fast. Let me know what you think. The Lab Model by JDCollie: The changes::. Stock (MPL-LG-2) science lab yields results much faster, but the science per unit data is much lower. A good starter lab, but large amounts of data are best processed in a better lab to maximise returns. For quick and dirty research for operations where you're not going to be returning the experiments to Kerbin, or don't want to wait for a better return. DSD-1 Slower science generation than the MPL, but double the total science yield (slower but you get more). Crew capacity for two kerbals to make the science generation rate more competitive with the stock MPL Increased running (EC) cost DSD-2 Much heavier than other science labs 50% more total science yield than the DSD-1 Crew capacity for four kerbals to maximise science return rate Same basic processing rate as DSD-1, best used with >2 kerbals 40EC/s running cost More Technical Details: In summary: Keeping a lab in orbit (or better, on the surface) actually makes sense now, and it won't require constantly restocking the lab with data to generate a good return. The increased speed of science generation is offset by either reduced long-term yields (less science per data) and/or higher weight/running costs. It's might be a little overpowered if you're not using CTT, or using a high science multiplier. Stock lab is best used for short missions where quick returns are preferred (lower yield, but the science gain is comparable to just bringing experiments back from e.g. Minmus) DSD-1 is a mid-level alternative with better returns outside Kerbin's SOI. Close to stock science yields, but faster. DSD-2 is best for long-term missions, such as exploring Jool, or as an addition to a base/station. The best long-term gains (better than stock), but heavier and more expensive to run (EC and Life Support) Required Mods: Module Manager (for stock MPL changes) Recommended Mods: This mod increases the speed of science labs vs. stock/vanilla. It's balanced to an extent but Community Tech Tree is highly recommended. Your choice of Life Support mod (to appreciate the difficulty of running a fully crewed DSD-2) Compatibility: USI Life Support - The DSD labs have the same equipment that USI Life Support adds to the stock lab Community Tech Tree TAC Life Support +many more. The parts are simple, so there shouldn't be many incompatibilities. Download Here Changelog Future Plans AVC Support CKAN Support Further balance changes will probably be needed Habitability changes for the larger labs (further USI Life Support compatibility) Snacks Life Support compatibility This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

I can not find this part in the technological tree. Saved ships they already own, can not be thrown (even in the sandbox). How will I recover science from my probes? Note: Sorry for spelling errors, I'm translating on google.

I feel like this could be done with a simple patch but I really don't know how to use MM. Is there anybody who can enlight me about this ? Thanks in advance

this mod solves problem of cheat-unlimited science from lab(s) (each stock lab(accompanied with 2 scientist and rover with instruments) gives you 3000 science from minmus each 3 years, which in turn makes even Duna visit meaningless) this goal is accomplished by 1. removing data concept from lab. 2. all bonus science from lab goes to corresponding research, so many labs can't give unlimited science on same subject (science bonus currently 100% of original science and limited by lab location and scientists levels and stupidity, 110% for kspie, needs testing) Features: 1. lab can send science(both collected, and bonus) without losses, but only if scientific subject already studied at lab at least up to 5% (bonus) by scientist on same celestial body, where it was obtained(last part required only if you want send research bonus itself). You can resend it as many times as you want (using button "Fair Transmit Science"), in case link was lost, or send updates if you collected(combined)/researched more. 2. lab bonus science can be viewed inside science archives ("from Lab" entries), after it was transmitted from lab. 3. lab can combine several experiments made by same equipment type in same conditions into one experiment, similar way of how its done in ksp, to use that feature you need to dock science lab and experiments with scientific data (at least two made in same location, and same type, but launched in different launches), and press button "FairCollectScience", it will copy data from experiments inside lab and combine them (if possible), you can do docking in sequence(same time not needed), and you could use instruments in same vessel as lab(as one source, you still need other(s)), but if you move data from experiment equipment, you would lose ability to combine it later(you still could study it inside lab but without ability to combine later with other experiment). this complex way is necessary to prevent cheating (multiple data scan by same equipment), and also because ksp don't mark scientific data with launch id, when created, so it can only identified from equipment it was created (while data still there). Science bonus depends both on current lab position (you would get 50% of max bonus if you within soi of celestial body, where scientific data is acquired, and up to 100% if situation and biome also matched) and (mutliplied by) cumulative level and smartness (1-stupidity) of scientists (formula is pow(level13*(1-stupidity1)+level23*(1-stupidity2),1/3) )/5 ), i.e. one level five scientist with stupidity 0, could give 100% science bonus, science processing speed also depends on lab location, and scientists levels. binary https://drive.google.com/open?id=0B0rgcOJPK_8XZ1JJMldFXzhXd0E 1.2.2 https://drive.google.com/file/d/0B0rgcOJPK_8XUVFIem1jMjgybkk 1.3.0 (just extract inside ksp data folder, and resolve conflict ModuleManager if exist (leave only latest ) ) source https://drive.google.com/open?id=0B0rgcOJPK_8XZHJTT2ljNF9qUWM on screenshot in processed queue first percentage is how much science did you collected (combined) on subject, second percentage is how much researched, second maximum (bonus) depends on first one, as soon as it reaches 5% you could send both to ksc. Fair toggle prepare(send) only allows study only up to 5.1% just to be able to send original experiment data to ksc without losses (using Fair Transmit Science). updated, initial compatibility with ksp interstellar extended added. in archives FairLab science can be seen such way (for example) P.S. i hope SQUAD would include that mod inside ksp. normal gui planned... don't forget lab in offline state while you leaving your vessel (i.e. you would think lab is working, but it is not) lab do auto shutdowns on resources absent, usually if you have a lot of research you could leave lab without supervision even longer than original one (as there is no data limit), but you should consider to move it from one biome to another, just to get maximum bonus. debug logging (enable) option is not saved, so each time you switch to vessel if you expect to see some bug you should enable it (and send logs (after bug occurs) here) science container functionality inside lab is fully enabled, but it is not linked to Fair lab code, so it will NOT allow combine scientific data, use FairCollectScience for that.