DMagic

I'm leaning towards using a station, rather than launching a rocket, for the next version of the test vessel. I think launches of big rockets are always going to be slow, and they are slow for many reasons, not just part physics. And since they basically consist of one big vessel continuously dropping off a few parts at a time, I don't think they will be the best indicator for how CPUs perform in KSP 1.1+. I also don't like the idea of needing a plugin to make the debris unload faster. I'll probably get the new version of the launch rocket working, but just keep it for myself for testing performance between different KSP versions. For the actual CPU test, comparing performance of different CPUs, rather than different versions of KSP, I'm thinking I'll make a big station. Something like a 300-400 part station core. Then launch 8 small vessels, then 4 medium vessels, then 2 large, and finally 1 very large vessel. I'm thinking each set of vessels should have the same total part count. It would be setup so you that all of the engines would be off, then you throttle up, and stage one set at a time. Then just wait for each set of vessels to get to the unload distance and fire off the next set. It should be simple and it should avoid other performance impacting elements, like aero effects, drag calculations, PQS ocean lag, and so on.

@Magic_Pants From the link in my previous post or the first post of the thread, the correct download package is SCANsat-v15.1.zip. Note that the release page on GitHub is out of order for some reason, but the direct links in this thread will point to the right release.

A test version is available on GitHub. It has been updated for KSP 1.1.1183. The only other change is that a broken SIGINT dish is no longer able to collect science. The only known issue is that the SIGINT dish reports as much too big in the editor and can only be launched with a fully upgraded launchpad; there may also be some issues with the indicator lights on the seismic hammer, but the score value for determining the amount of science gained appears to be correct. Let me know if any other issues come up.

Dev version bugs go in the dev version thread. Full logs would also help.

Version 15.1 is out; get it on GitHub. This updated fixes the problem with the ground tracks and landing location indicator. It is also updated for KSP 1.1.0.1174 and includes some minor Unity 5-based performance improvements. Resource scanning seems to work fine when using the latest version of Module Manager

There doesn't seem to be much that needed updating for KSP 1.1, mostly some Unity 5 Component stuff and a few changes made to FinePrint code. I'll see about getting a pre-release version of this out for testing, probably some time this weekend. I also found a new function in ModuleScienceExperiment that could be interesting. It looks like they added a cool down timer for science experiments. I'm not sure if it actually used by any stock experiments, but it might be an interesting feature.

I probably won't get around to releasing a 1.1 update during the pre-release. But it should update soon after that.

@JPLRepo Looking at the fields in the ScienceLabSearch class I'm guessing it just builds a list of all the science labs on the current vessel that: 1; are manned, 2; have space, 3; haven't processed that data, 4; aren't currently processing anything. Then just sends your data to the next valid lab when you click on the lab process button.

@FreeThinker It's in KSP.UI.Screens.Flight.Dialogs. The ExperimentResultDialogPage constructor requires a ScienceLabSearch object (with a Vessel and ScienceData object), but otherwise seem to function the same as before.

Here are some more results from a lower powered machine. The full specs are: Surface Pro 4 - m3 6Y30 - 2.2GHz | 4GB DDR3L RAM | HD 515 Results for both 1.1 and 1.0.5 include stock and pre-1.0 unload distances. All 1.1 tests were run in the x64 version. The results here show a much bigger relative improvement. It goes from essentially unplayable in 1.0.5 to sort-of reasonable in 1.1. I have two ideas in mind for new 1.1 tests. One is the new rocket that was shown a little earlier in the thread. It should better demonstrate improvements when multiple vessels are loaded. Another is to put a station in orbit where it would be away from PQS lag, and away from any aero calculations. The station could just fire off several vessels with varying part counts over the course of the test. These will all have to wait until the full release though.

To add to my previous point about hiding the UI, this seems to handle all of the cases where you want to hide something. void Start() { GameEvents.onShowUI.Add(UIOn); GameEvents.onHideUI.Add(UIOff); GameEvents.onGUIMissionControlSpawn.Add(UIOff); GameEvents.onGUIMissionControlDespawn.Add(UIOff); GameEvents.onGUIRnDComplexSpawn.Add(UIOff); GameEvents.onGUIRnDComplexDespawn.Add(UIOn); GameEvents.onGUIAdministrationFacilitySpawn.Add(UIOff); GameEvents.onGUIAdministrationFacilityDespawn.Add(UIOn); GameEvents.onGUIAstronautComplexSpawn.Add(UIOff); GameEvents.onGUIAstronautComplexDespawn.Add(UIOn); } void OnDestroy() { GameEvents.onShowUI.Remove(UIOn); GameEvents.onHideUI.Remove(UIOff); GameEvents.onGUIMissionControlSpawn.Remove(UIOff); GameEvents.onGUIMissionControlDespawn.Remove(UIOff); GameEvents.onGUIRnDComplexSpawn.Remove(UIOff); GameEvents.onGUIRnDComplexDespawn.Remove(UIOn); GameEvents.onGUIAdministrationFacilitySpawn.Remove(UIOff); GameEvents.onGUIAdministrationFacilityDespawn.Remove(UIOn); GameEvents.onGUIAstronautComplexSpawn.Remove(UIOff); GameEvents.onGUIAstronautComplexDespawn.Remove(UIOn); } private void UIOn() { showUI = true; } private void UIOff() { showUI = false; } private void OnGUI() { if (!showUI) return; //GUI stuff... } Just keep in mind that you'll probably want two flags to check if your UI should be visible. One for the events shown above, and a second standard flag for hiding or closing your UI through other means.

1.1 compatible version can be found here: No promises about stability.

If anyone is brave and wants to help out I released a KSP 1.1 version of SCANsat; get it on GitHub. As far as I can see all basic SCANsat functions are working properly. I haven't tested upgrading from old versions, so you should make backups if you have scanning data you want to keep. Integration with MechJeb is not included, delete any SCANmechjeb.dll files you might have remaining in your SCANsat/Plugins folder. SCANsat resource scanning requires Module Manager, I'm not sure if a KSP 1.1 version of that is available, but resource scanning won't work without it and hasn't been tested. The only error that I can see so far is that the ground track indicators don't work. Please let me know if anyone finds anything broken.

SCANsat version 14.9 and Contracts Window + version 6.1 should both point to SpaceDock. The download link can be seen in CKAN's meta files here. If they aren't working correctly it could be a problem on CKAN's side.

@FrancoisH It already is, that goes for Contracts Window + too. If you are referring to old versions, then no, I'm not going to go back and change all of the link references.

OK I have a few initial results with the old CPU rocket. All tests were run with the vessel unload distances set to their pre-1.0 levels (2.25km, instead of 22.5km in flight and 15km in suborbital): There are a few things of interest here. The first is the 1.0.5 to 1.1 x64 comparison, in blue and yellow. There is a significant increase in performance. Another is that there is a significant difference between the 32- and 64-bit versions, in orange and yellow. And I swear that the results in green are what I got when I ran it in 0.25. I'll have to run it again when the final version is released, but that result is a little disappointing. It's likely that this rocket doesn't accurately show some of the performance increases, since the debris are quickly unloaded and it's mostly just one vessel. My new CPU rocket might give more representative results when it is ready. If anything this is just an indicator of how badly performance has degraded in pre-1.1 versions. I should have some results on a weaker machine later today, too.

For people using RenderManager we will presumably have to manually handle hiding the UI. There are GameEvents for every circumstance that I know of where the UI should be hidden: OnShowUI and OnHideUI for Alt+F2 OnGUI*Spawn OnGUI*Despawn for the Space Center complexes, like mission control, R&D, etc... Using these will prevent your window from being drawn above those screens (as far as I know OnGUI elements will be drawn on top of any other type of UI object, using the new or old system).

I will update properly tomorrow; many changes are needed for this to be a more useful benchmark. Don't submit results for now. @sparkybear I'll check these results and add a few of my own when I get a chance.

Making transparent mesh textures for large parts like that is really tricky. For one, there seems to be a large difference in the final outcome based on which format the texture is in. I seem to get OK results using nVidia's DDS Photoshop plugin, but I imagine other converters might have problems (I know, for instance, that the PS plugin works fine for small icon DDS textures, but others don't work at all). Then you can run into problems with mipmaps and visible transitions between the different levels, which are especially noticeable with transparent textures. The lower quality mipmaps can sometimes end up with very jagged looking transparent sections, somewhat like you see at the top of the dish. You can try not using mipmaps at all, but the results are usually worse, with lots of artifacts like you see at the bottom of that dish, where detail is replaced by flickering bands. For me, the best option was to auto-generate mipmaps with PS's DDS plugin, then re-load the full file, with mipmaps, and manually edit the lower quality sections. It can be a pain, and I have no idea of what options are available if you aren't using PS. And then, like @Nookos mentioned, there aren't many options for transparent shaders, I think there is just one for cutoff transparency, so you can't have any normal maps or specularity.

Problems with other mods will have to wait until 1.1. I believe they are all known issues, but we'll see when things get updated. @Loren Pechtel Do you mean the biome planet overlay? The one that gets drawn over the actual planet surface. I'm not really sure what you mean, but the planetary overlays (stock and SCANsat) are always visible in both map view and normal view. It's only once you go below a certain altitude that the actual planet surface fades in and the overlay fades out.

Using DMagicScienceAnimate strictly for its animation properties probably isn't the best idea, but it shouldn't hurt anything either. It's too bad no one has taken up, or improved upon StupidChris' Advanced Animator module. ModuleAnimateGeneric has been improved, but there is still a lot of customization that would be nice in animation modules. And now that I think about it, making a custom antenna module might be interesting. Something that would allow for breakable dishes, oneshot (I think that was the config field that used to (or still does?) allow for one way animations) animations, continuous power drain, etc... As for using Orbital Science as a dependency for its science experiments, that's fine. I wouldn't mind even if someone wanted to just make alternate part models and textures for some of the parts.

Before getting too excited about how well it was running on a laptop, we should keep in mind that this was an extremely high end machine. The thing had an i7 6700hq, which is about as good as you can get in a laptop, and better than a substantial amount of desktop CPUs.

Docking ports require a very specific setup and won't work by just copying the module from the standard part. You have to specify which transform is to be used for the actual docking location on the part. For that you need to know the names of the transforms in the part, if they are in a suitable location (at the edge of the model) and if they face in right direction. There are probably some parts that could be made to work as docking ports, but I doubt any of the standard structural parts will work.

I re-uploaded the .dll file on GitHub. I seem to have misplaced the original DropBox upload , so this only includes the plugin file. You'll need to download the last version from @SirDargon (0.08.2) and replace the .dll file with the file included here. Let me know if it's working correctly.

@Kill_off This doesn't do anything to the asteroid masses, it just internally assigns a classification used only by Orbital Science. @Napseis What do you mean by doesn't interact with the pods? The science value gained after collecting data is based on the same value used to set the indicator lights and the right-click menu percentage value. There is a limit to the amount of seismic data that can be collected though. So if you collect data from a biome without pods (at, say, 60% value) and recover it, then go back and collect data with pods (at 100%) you will only get the remaining amount of data (40% of the total).