DMagic

For the Tylo.att, "Northern Mesa" is written as "Morthern Mesa", I think that's the only remaining typo.

I had a probe at around 7.8km around the Mun at an inclination of around 80o. It stayed in orbit for months and never ran into the ground, it's possible that it will eventually, but I don't think so.

Thanks for these results Sirine. At some point I'm going to stop neglecting this thread and figure out a good way of incorporating all of these frametime results into my analysis. Maybe checking if CPU power correlates with frametime variance, or the Leonidas3 framerate, or maybe plotting the frametime difference between consecutive frames. There are several options for using all of that data.

That's one way to fix the problem. You can also just tell Steam not to keep the program up-to-date (it's in the game's properties menu). Or you can just copy the whole KSP folder out of its location and play it without launching Steam, you can even uninstall Steam if you really don't want it around.

The real problem with dropping back to a low Kerbin flyby is that it is extremely difficult to set up ideal transfers this way. Everything has to be lined up correctly, and you have to take into account that it takes around 2 days (I think) to drop back down to Kerbin periapsis. There is some leeway in the positioning, of course, but if Minmus is on the wrong side of Kerbin during a transfer window then you will have to wait for another. That said, it's still a lot of fun to do. You can also change your inclination a lot when you are out by Minmus, making transfers to Moho quite a bit cheaper. As for the best height for a refueling station, I think somewhere around 50 - 100km is pretty good. It's easy to get to and from the surface, you can timewarp at a decent speed, and it doesn't take that much to break orbit. And don't worry about any benefit from the Oberth effect around Minmus, your orbital velocity is so low that it probably makes almost no difference.

Really? All of them? Sounds unlikely... It usually takes a week or so to get all of the mods updated after a new release, if they need to be updated at all.

You can use one probe, or one scanner (or multiple scanner types on one probe) for as many planets/moons as you want. You could make a complete map of one planet at a time, but doing it like you suggest, multiple quick flyovers would take a very long time and require constant attention. The scanners have a pretty small scan width, so each pass would only scan a tiny strip of the surface. Buy with enough patience you could do it.

That's why I made my CPU performance database. Everyone has different ideas about what levels of performance are acceptable and what they consider "laggy". That makes it hard to get a good sense of how well any given computer performs in KSP. Also keep in mind that different types of parts can significantly alter performance, as can some mods.

I think this drill is ready enough to release. I've worked out most of the bugs, but there could still be some issues that I haven't though of. It would be great if I could get a few people to try and break this before I make a wider release. Download link: http://www./download/bzewcpvh6gfptl7/DMagic_Orbital_Science_v0_5_1.zip See the previews above and on the first page for more info and images. The drill is intended to be used on atmospheric planets to search for signs of biological activity. It can be used for a total of six times and store three reports for full science value. It's mostly self explanatory, but it requires juggling two science data lists, so there are two different "Review Data" right-click buttons that can be used. Most of the time, though, the initial data will be either stored or transmitted right away and you probably won't see the right click button for this list, only the "Review Stored Data" button should be commonly used. I think I've worked out the part orientation/animation issues. The animation played is based on the drill's orientation relative to its parent part. This works out fine in most cases, but when attached directly to some structural components can cause the wrong animation to be triggered. Use cubic octagonal struts to get around this, either by laying one on its side, or turning one around, so that it faces into its parent part, then attach the drill. You can preview the animation in the VAB. The science lab seems to be functioning correctly now. Data can be processed either before or after storage (to process data before storage the lab would have to be on the vessel with the drill). You can do so with the lab's right click "process data" button, or through the drill's "review data" button or action group. There might still be some quirks associated with this, storing three experiment reports in the same part complicates things. There are a lot of debugging options left uncommented in the plugin, check the debug log (alt + F2) if you're having issues, it might help. I've also included science reports for the basic biome set in Trueborn's Custom Biomes plugin. The reports should be ignored if you don't have the plugin, or if you use a different set of biomes. I'm working on adding biome reports for the other parts as well. Let me know if anyone runs into any other bugs or thinks of anything else.

I'm in the process of adding reports for your default biome maps for my own set of parts. Though for now I just have reports for my newest part, that's a lot of reports to add. I did notice one thing though, I'm not sure if this is intentional, but Duna's ice cap biomes don't really match the ice caps on the planet. They extend about twice as far as the biomes do from the poles. I guess it doesn't really matter, but it might be a little confusing to be sitting on the ice and not get the poles back as the biome. Also, the green marker you use for your position on the map can sometimes get lost in green colored biomes. I like this idea a lot though, and at the very least the basic biome set should make a nice stand-in until Squad can release full biomes for every planet.

I tried this once, adding a science lab module to a command pod to make testing easier and had exactly the same problem. I've seen a few other people run into this as well. I never really played around with it to try fixing it though. Does the FusTek part have its own ModuleScienceExperiment or ModuleScienceContainer modules? Maybe those interfere somehow. Try adding ModuleScienceLab to another part, maybe a crew container, and see what happens.

What are your material import settings in Unity? They should be on the first tab of the inspector when you click on the "mk2bay" file in your Assets/mk2bay folder. You can try changing the settings or turning off import materials and see what happens.

We do, but it doesn't address the FXAA issues and it isn't really a good alternative to a more complete settings menu. Most people probably don't know about, or want to hassle with, the settings.cfg file (most people probably won't even be able to open it). And having a specific setting for ocean terrain would make a world of difference in how well the game runs for many people. Most computers can handle the solid-ground terrain settings at default or high, but the ocean terrain levels screw everything up and require a work-around to get good performance at high terrain settings.

Yeah, Kethane flows like monopropellant, it doesn't matter how it's connected as long as is it's on the same vessel. KAS pipes sort of work like docking, but apparently not entirely. This screws up fuel flow and causes this issue, there is a really in-depth tutorial on fuel flow that explains exactly how it works. The easiest way to set it up is to attach a little fuel tank to the converter then use TAC fuel balancer to shift around, this is much better than manually filling up a bunch of tanks.

Go here for more info: http://forum.kerbalspaceprogram.com/threads/35664-Kethane-Usage-and-Proper-Fuel-Routing In short, you need a direct line for fuel flow from the fuel tank to the converter. You can use fuel transfer pipes for this, or you can setup your vessel with a fuel tank connected to the converter in the right way. The safest way is to attach a fuel tank directly to the converter, then transfer fuel manually if you have to. And if by pipe, you mean KAS pipe, then you should know that fuel doesn't flow through them, at least not in the way you might expect. You have to manually transfer fuel across KAS pipes when using a Kethane converter.

This only reloads parts and their .cfg files. It doesn't work for .dll files. Trigger Au has a good plugin for speeding up the loading process a bit in the way Faark described. There are a few these floating around other places too if you look. You can also setup a batch file to copy the newly built .dll to your gamedata folder and start KSP, which helps a little. But between those things and deleting unnecessary parts there isn't much you can do to make the development process quicker.

In terms of ambition and scale, I think my Moho mission was the best. All of my space stations and the base came out really well. But it took up an absurd amount of time to complete it all, something like 200 hours over more than a month. But I think my favorite was my Eeloo mission. It was much smaller scale, but everything worked out perfectly and didn't require so much tinkering or have any tedious aspects to it.

Thanks for this, it's really helpful as this system isn't all that easily understandable. There are a few other things that some people (or maybe just me) might be interested in. Some of these variables can be observed in your persistence file, which can be of use in some situations (though if you don't know what you're doing you should probably stay out of the persistence or quicksave files). First though, there is one thing that I don't believe was covered in the first post: the Data Scalar value. This is specified in the ScienceDefs.cfg file for each experiment. It affects the data size for each report: Data size = Data Scalar * Experiment Base Value * Sci Value * Sub Value This affects the transmission and data processing times and the amount of electricity required for each. This is also visible on the Science Summary page, the thing that shows up when you recover or end a mission. The Data Gathered number is equal to the Data Size. The Data Value number is actually: Data Value = (Sub Value * Sci Value) / Data Scalar This prevents the data scalar from affecting the total science points. Now on to the information in the persistence file, which can be found under: SCENARIO { name = ResearchAndDevelopment which is near the top. The first entries are for the tech nodes, they show which nodes have been researched and what parts are available within. Under that are the science entries, there is an entry for every science report that you have collected. An entry for the goo container looks like this: Science { id = mysteryGoo@MunSrfLandedEastCrater title = Mystery Gooâ„¢ Observation from the Mun's East Crater dsc = 1 scv = 1 sbv = 4 sci = 0 cap = 52 } The id, title and biome are on the first three lines. The next line is the Data Scalar, dsc = 1. Most experiments have a value of 1, but some are higher (the atmospheric scanner, I think, is much higher). The next value, scv = 1 is the Experiment Scientific Value, the decaying number that affects repeated experiments. Next is, sbv = 4, this is the Experiment Subject Value. sci = 0 is the total amount of Science Points collected so far for that experiment. In this case the experiment report has been collected, but the data has not been transmitted or returned, so no science points have been given yet. The Science Cap is last, cap = 52. Looking at this information might be useful for troubleshooting or mod creation, so I hope it's helpful to someone other than me. These values can also be accessed and changed using a plugin, but that's a different story.

I think I've fixed most of the issues with science collection and weird edge cases; things like transmitting multiple reports at the same time with more than one transmitter, or docking to a station with more than one lab, but only having one of them operational. I've also got the science values reporting correctly, I had things setup wrong before so I was getting less science than I was supposed to. I've uploaded the plugin source to GitHub in case anyone is dying to check it out. The new drill orientation function that I'm using works better, and isn't affected by latitude like the last one. It does have some issues though because it detects rotation relative to the root part, using the parent part might give better results. Either way, there is a preview function in the VAB/SPH, so that you can check which way the drill will animate (at some point I do want to add ground-contact detection, so this will all actually matter, and the drill body does have a collider on it). It seems to work ok for regular situations, where the probe core or command pod is facing up from the ground, but things like cockpits, or putting the probe core on the front of a rover will trip it up. Edit: Yep, using the part.parent.transform.up instead of part.localroot.transform.up seems to work a lot better. And you can use a cubic octagonal strut to get the right results if you have some weird setup that doesn't work right, either by flipping the strut around so that it faces inside its parent part, or by laying it on its side. Doing something like that and checking the preview should be enough. Here it is working correctly, the debug menu shows the current rotation value and tells you what values will play each animation. This one doesn't work so well.

Thanks for those teal'c, multiple results at different clock speeds are great because they give the clearest indication of their effect on performance, I don't have to worry about settings or GPUs, or any other complicating factors.

If you're looking for the SrfLanded, InSpaceLow, etc... you should try poking around with ExperimentSituations, I'm not sure exactly how it works as I've only been using it to return one specific result. As for biomes, check back a few pages. For KSC, LaunchPad, and Runway, you'll need to find another way (I use vessel.landedAt, but that only works on the surface) because the biome check will only return "shores" for anywhere around the KSC.

I think that I'm finished with the model, texture and animations. Everything looks ok to me, but there might be a few more tweaks to make. All of the basic functions seem to be working right. The drill can collect, transmit, store and return multiple science reports, and it stops functioning after a certain amount of experiments have been performed. The part maintains two lists of science results: the stored data list, and the temporary list used before transmission or storage of data. Only the stored data can be returned to Kerbin for credit or picked up by EVA Kerbals. Science lab integration works, but there are a few kinks. I'm not sure if I'll be able to get around them without modifying the science lab itself, which I'm not going to do. The reset and data processing functions have to be initiated through the part itself, not by right-clicking on the science lab, that's a little annoying, but I don't think it's too big of a deal. The part rotation function that I was using to determine which drill animation to play doesn't seem to work. It's fine at equatorial latitudes, but as you move closer to the poles it stops giving the same results. I have some other methods that I can try, but they will need lots of testing, as will all of the other functions. Other than that I just need to write the science reports (I'm planning on including reports for Trueborn's Custom Biomes plugin too), and add a few more finishing touches.

The first post of this thread says that's not how it works. I think Kethane generates the deposit data randomly when you start a new save file. So I guess the detector is revealing that data and putting it on the grid, but that's still not quite the same as just revealing parts of an image.

Why would someone download a mod if they didn't already have an idea of what it is for or what it does? I agree that when your download package has some special requirements, such as having multiple different versions available, or something like alternate textures, then some instructions should be included. But detailed usage instructions are much better off in the forums where people can ask about them, though it would be helpful to add a link to the forum thread to make it a bit easier to find. And while it's fine that you don't care about a changelog or a license, many people do, and it's important, and sometimes required, to include such things.

Thanks for all of the results, I've added them to the first page. I also added back the CPU comparison chart. I left off the FX8350 that might have been running the FRAPS video recorder and the i7 3770 that was running on the integrated GPU, but otherwise everything lines up pretty well. Everything in the chart is the same as from before 0.23, and the description and sources for most of the benchmark values is below it on the first page.