DMagic

@fatcargo Do you have FAR installed when any of this happens? That caused problems in the past, though I thought I had fixed that. I've always heard that IR can have problems when attaching docking ports to movable parts, so that might be causing some issues. Do you have a craft file, or pictures of the stock rover that was having problems? I can try to replicate the issue. @tjt I'll see about updating the default values. It's possible that those have been changed since I last checked.

That's not true. SCANsat doesn't store map data, it stores scanning coverage data. If an area of a planet has been scanned with a resource scanner, SCANsat will see that it has been scanned and report the accurate resource concentration for your particular game.

@MedwedianPresident Not really. The only way to transfer maps to a new save is by manually copying the map coverage data from an old save and pasting it into your new save. Since editing a save file is a good way to break it I'm not going to endorse that, or explain in detail how to do that. Like I said, the next version will have an option to turn on the cheat "fill map" button. Also, the overlay mode's terrain maps are basically instant and use pre-computed data (generated once each time you start KSP). The draw-back is that they are based on very low resolution data (360*180 maps, the same as is used by the continuously updating small map) with some interpolation to make them look a little nicer.

The idea with the redesign is to give scientists a greater role in setting up the experiments and to make them more of a long-term project, rather than click and be done. Experiments will take place over time, but will work differently from science labs. Rather than a slow trickle of one or two science points per day, science will be generated in discrete amounts. So once 50% of the data has been collected a science result for the basic version of that experiment will be generated, this will be worth 50% of the max science and can be transmitted or returned like any other science data. You can then wait until 75% for the next data set, and 100% for the final data set. But it isn't necessary to collect all three, you can just let it run until it reaches 100%, collect the final data set, and return that, you will gain the same amount of science points either way. The level of the scientist setting up each experiment and the complexity of the experiment will determine both the rate that science is generated, and the maximum amount that can be generated. So an experiment setup by a low level scientist might not be able to generate the max amount of science, it could stop at 50% or 75%. You could revisit the experiment with a higher level scientist, or just move on to other areas. Once a few final issues have been addressed and some initial balancing has been done the first phase should be ready. The second phase will work on better ways to control active experiments and communicate their status to users (right-click menus can only get you so far ). The third phase will focus on adding unique feature to some experiments, allowing more than just the scientist level to affect data collection. Experiments could be calibrated by, say, crashing a probe into the surface for the seismometer, or drilling into the ground with a hot drill bit for the interior heat probe, and so on.

@NathanMcGuire30 The two things that most affect the map generation speed are the size of the map and your CPU. Bigger maps can take much longer to generate and slower CPUs are obviously slower. There are a few ways that SCANsat tries to minimize this, only the first time you generate a map for a planet should be slow, it has to generate and cache all of the terrain elevation data. After this first time you can refresh the map, switch to different map types, or change the map projection type without having to recreate the terrain database. Even on slower CPUs refreshing the map shouldn't cause much noticeable slow down. If you change the map size, or switch to a new planet, the database has to be regenerated, which will slow things down again. It's best to pick a map size and stick with it, and to avoid switching between planets as much as possible if the map generation speed is too slow. @MedwedianPresident No, but I should add a cheat option to allow this (something that will have to be set in the config file, not in game), so that you can fill in any given map, or all of them at once.

Also note that OnStart is called after Load, so all persistent KSPFields are already parsed for OnStart. There is an OnAwake method that is called before all of the loading steps, in case you want to do something before loading. Just be careful not to use the standard Unity Awake method, that would hide the base module's Awake and screw things up. I don't think there is a base Start method, but you are probably better off using OnStart in most cases. The persistent KSPFields are saved and loaded before OnLoad and OnSave are called. So if you want to change anything for those values in OnSave you'll either have to directly modify the config node, or use your own fields. And there is also the LateUpdate method, called each frame after all Update calls have been made. I don't think there is an OnLateUpdate method, just the standard Unity method.

@subyng It originates from the dish itself, which comes out above the part's collider. So if the beam has to go back through the part it will run into that collider and won't work. I can probably change this so that it originates from the center of the part, which I think will at least allow the beam to pass through the scanner.

@subyng Do you have a screenshot of the setup? Due to some changes Squad made in how asteroids work, the targeting method used for tracking the other instrument can be blocked by other parts on your vessel. So if there isn't a clear line-of-sight, with only the asteroid between the two instruments they won't work. I'm not sure if the instrument itself is enough to block it though.

@EliasDanger Contract Reward Modifier has a slider for adjusting the duration of contracts, it can't be set to infinite, but its max of 10X standard should be effectively the same thing. I haven't tested it with newer versions of CC, but in theory it should allow for setting the duration of all different types of CC contracts in addition to standard contracts.

@DDE Not sure what you mean by unlinking the two maps. Both have resource selection menus. The different rules are there because the small map has a more accurate representation of the resource distribution and allows for essentially unlimited zoom in.

@baldamundo I don't see anything about a SIGINT in that contract. It's asking for a recon telescope.

@baldamundo You have Contract Reward Modifier and Contract Filter? Are you using both to set limits on the number of each contract. Maybe try removing the limits, or remove one or both of those (Contract Filter seems to have lots of errors in the log file, and uses a different method for rejecting contracts that might not play nice). I'll have to update to prevent this kind of non-functional contract showing up in the offers list, but for now there might be workarounds to prevent them from showing up.

@DDE What are your SCANsat resource scanning options set to? Have you checked the KSPedia entry, or the SCANsat wiki? They both have lots of info about resource scanning.

@Freshmeat No, but that is something that should be relatively simple to add. @severedsolo Thanks, I'll include those changes in the next update. @Loren Pechtel Which version of MechJeb do you have? And is the option to use MechJeb integration available and selected in the Settings window? I'll have to look into contract issues, but duplicates may be a CC problem.

@eaglepilot7ac Something else is probably changing the costs with Module Manager. If you have the Community Tech Tree then there is a file in the Resource folder of Orbital Science that adjusts the cost of many parts. Other mods might have their own MM patches to change those values. Your best bet is to make MM patches for yourself and put the :FINAL tag at the end of each patch: @PART[dmUSGoo]:FINAL { @entryCost = 10000 @cost = 8000 }

I've been using that old part action window click-through workaround in 1.1.x and it seems to be fine. But looking at the code again it seems like a horrendously inefficient method. That's a FindObjectsOfType and two Linq statements for every GUI frame when the mouse is over your window. I suppose if this is an infrequently used window that might be ok, but for anything that is meant to be open a lot it seems very bad. UIPartActionController would seem to be the best option for looking for open part action windows. Unfortunately the simple list of windows looks like it's private, so the only way to get the active windows is by searching through for every part. UIPartActionWindow window = UIPartActionController.Instance.GetItem(part, symmetry bool); I'm not sure that running through each part is faster than the FindObjectsOfType method, it probably depends on how the UIPartActionController method works and how many parts you have. And you would have to run through the parts for all unpacked vessels to get accurate results... Making a public version of that internal window list would really help.

@LessrOf2Weevils Did the big map get dragged off screen? Try the Reset Window Position button in the settings window. @severedsolo I haven't had a chance to look at what needs fixing. Is it just the way the names display because they don't have a target planet assigned that is a problem? If you could take a quick look that would be great, and I'll probably update soon with a few other fixes included.

CapCom 2.4 is out; get it on Space Dock. This version includes support for Contract Configurator 1.15.x. It will display all available CC contracts and show the accurate contract limits for each difficulty level. It does not display contracts that have unmet requirements. There is an extra button when CC is detected that forces CC to refresh its list of offered contracts. This can be used outside of the Space Center to check for any changes in the available contracts. The button include a 30 sec timer to prevent spamming the refresh function (which can take some time to fully complete). This also fixes an issue that prevented different window size scales from being applied. The existing version of Contract Parser and Progress Parser remain compatible, no changes have been made to either. Let me know if anything strange happens when running with Contract Configurator.

@vardicd

No, it's part.partInfo.title. The Part class itself doesn't store the title anywhere that I'm aware of.

@cyberpunkdreams I would need to see the files to say anything for sure. If the experiment hasn't ever been run then it may be some other mod interfering. Does the same thing happen with other experiments, or with a newly launched vessel (you can run the magnetometer on the launch pad to check)?

DMagicScienceAnimate seems unlikely to be causing problems when loading the tracking station. Its code only runs on active part in the flight scene or editor.

@KoolBreeze420 What does the contract say? There are two recon telescopes included, so it presumably wants either of those, but I would need to see the exact contract text to say for sure.

Portrait Stat version 11.0 is out; get it on Space Dock. It fixes an error with part highlighting when a Kerbal goes on EVA. @Loren Pechtel This may not be a Portrait Stats issue. Since those icons show up against the black background it looks like everything is getting setup properly (the star icons are from stock KSP, they are just made to show all of the time here). I'll see about getting a version with adjustable delay timing if this problem continues.

@Loren Pechtel Does this happen without Portrait Stats? Do you have log files? When you first switch to the rescue vessel does the portrait show the static first, then go black, or is it just black? I'm also wondering what happens if you change some of the Portrait Stats settings, try setting the showAlways to false, or disabling both tooltips (in the Settings.cfg file). I'm not sure why this would be happening. Portrait Stats just adds a few things to the portrait object after it is finished loading. The only thing I can think of is that there might not be enough of a delay before Portrait Stats starts accessing the portraits. I can try increasing that value (and maybe making it configurable) if the problem persists.