DMagic

Only if you don't have any active contracts from SSlite. I'm not sure what will happen to completed contracts if you remove it, but I think it should be fine, maybe make a backup before you try. Alternatively, if there is a problem, you could just edit the maxSimultaneous value in the ContractPackScanSatLite.cfg file. Malah released a set of [thread=99869]MM configs[/thread] for adding all of the SCANsat modules to stock parts. You can look at that for reference. Basically you just need to add the SCANsat part modules to whatever part you want to use; animations may or may not work, you'll have to experiment. Resource scanners are a bit more complex, you'll probably need to add in the stock scanner modules as well as the SCANsat resource scanning modules (which can be found in the SCANsat/MM_Parts folder) for them to work right. That's how it's supposed to work. The lower value is a cutoff (because why would you want to see resource concentrations below that value?) and the upper value is a color limit, it just sets the max color value. I can't see any reason why someone would want to hide resource deposits above a certain concentration. One thing I might want to add here is a simpler way of adjusting those values. I think a simple set of controls could be added to the resource overlay window for setting those min and max values so that people won't have to dive into the color management window every time they want to adjust it.

SCANsat parts don't and never have produced heat. Runaway heating problems are probably caused by the buggy stock heating system.

Version 14.2 is out; get it on Kerbal Stuff. This update includes some RAM and performance improvements, additional RPM functionality (* see below), numerous minor changes to the information readouts for the maps and the instruments window, part tweaks, a modified version of severedSolo's SCANsatLite contract pack (they should work fine at the same time, but will be a little redundant), and various bug fixes and other changes. The full changelog has all the details. Version 14.2 - 2015-8-29 ------------------------ - Performance and RAM usage improvements - Storage modules for each planet use less RAM - Planetary overlays use less RAM - Biome overlay texture size can be changed independently of resource size - Planetary overlays generated on a different thread when possible - This reduces or prevents the slight freeze or hiccup when generating a new overlay - Raster Prop Monitor - Additional functions added to RPM panels - The standard MFDs use the four buttons on the left for resource and anomaly/waypoint overlays - ALCOR pods also have additional functions where possible - Increased map rendering performance by reducing map texture size - Map texture size and resource overlay quality can be adjusted in the RPM configs - Prevent the non full-screen panels from drawing maps underneath opaque sections of the display (ie the left hand ALCOR panel) - A Module Manager patch is required for full ALCOR MFD functionality - Parts - Slight reduction in size of SAR and MultiSpectral scanners - Proper use of MODEL node scaling; fixes KIS inventory size problems (thanks Kerbas_ad_astra) - Slightly increased scanning width and altitude parameters for M700 (clamshell) resource scanner - Contract Configurator Contracts included - Based on a slightly modified version of severedsolo's SCANsatLite pack - SCAN agency and manufacturers group added - Big map and KSC map - Resource overlays now use the same quality settings as the planetary overlays - Resource mouse-over info now follows the same narrow-band scanner restrictions as planetary overlay tooltips - Slope added to mouse-over info for terrain scanned with high-resolution terrain scanner - Small map - Biome maps available on the small map - The vessel info readout will display the current biome (if scanned) for each vessel - The altitude readout for each vessel is now dependent on scanning coverage - Instruments UI - New rules for the altitude and slope readout - Below 1000m full height-above-terrain and slope info is given regardless of scanning coverage - Above 1000m altitude the readout is based on low or high resolution terrain scanning; slope is only given for high resolution scans - Color Management Window - Planet selection boxes available for terrain and resource color configs - Fix possible bugs created by adding and deleting mod planets - Misc and bug fixes - Resource overlay colors properly use the assigned abundance ranges - Added a resource overlay control window toolbar button - Update the active vessel in the instruments window - Various minor performance improvements - Various minor UI tweaks I haven't updated the docs yet, but nothing substantial has changed as far as usage goes. There shouldn't be any problems updating from a previous version (keep your SCANsat/Resources/SCANcolors.cfg if you have any custom color settings that you want to preserve). * For full RPM functionality in pods using the ASET props use this Module Manager config. @PROP[ALCORMFD60x30]:FOR[SCANsat]:NEEDS[RasterPropMonitor,ASET] { @MODULE[RasterPropMonitor] { @PAGE[pALCOROrbitMap60x30] { @BACKGROUNDHANDLER[JSISCANsatRPM] { @buttonHome = 6 buttonRight = 5 buttonLeft = 1 buttonR9 = 8 buttonR10 = 7 startLine = 120 stopLine = 390 mapDivider = 2 resourceInterpolation = 4 } } @PAGE[pALCORClearMap60x30] { @BACKGROUNDHANDLER[JSISCANsatRPM] { @buttonHome = 6 buttonRight = 5 buttonLeft = 1 buttonR9 = 8 buttonR10 = 7 mapDivider = 2 resourceInterpolation = 4 } } } } @PROP[kOSTerminal]:FOR[SCANsat]:NEEDS[RasterPropMonitor,ASET] { @MODULE[RasterPropMonitor] { @PAGE[pALCORMapOrbit50x18] { @BACKGROUNDHANDLER[JSISCANsatRPM] { buttonHome = 4 buttonRight = 6 buttonR9 = 5 mapDivider = 2 resourceInterpolation = 4 } } @PAGE[pALCORMapLanding50x18] { @BACKGROUNDHANDLER[JSISCANsatRPM] { buttonHome = 4 buttonRight = 6 buttonR9 = 5 mapDivider = 2 resourceInterpolation = 4 } } } } @PROP[ALCORMFD40x20]:FOR[SCANsat]:NEEDS[RasterPropMonitor,ASET] { @MODULE[RasterPropMonitor] { @PAGE[pALCORMapOrbit40x20] { @BACKGROUNDHANDLER[JSISCANsatRPM] { buttonHome = 4 buttonRight = 5 buttonLeft = 6 buttonR9 = 7 buttonR10 = 8 mapDivider = 2 resourceInterpolation = 4 } } @PAGE[pALCORMapLanding40x20] { @BACKGROUNDHANDLER[JSISCANsatRPM] { buttonHome = 4 buttonRight = 5 buttonLeft = 6 buttonR9 = 7 buttonR10 = 8 mapDivider = 2 resourceInterpolation = 4 } } } } Let me know if anything breaks, explodes, consumes Jeb, etc...

You probably converted an agency logo to DDS. Don't do that. That converter somehow screws up the small agency logo images when converting from PNG to DDS, the only safe way that I know of to convert those is through PhotoShop with nVidia's texture tools. Otherwise those small agency logos should be left alone.

Groovy. Will that affect other instances of using that syntax? Like what you have for selecting target bodies for Field Research. I'm using a similar method, but haven't really gotten around to testing if it's actually working.

There is little difference in performance between otherwise similar i7 and i5 CPUs. Those CPU's don't have any significant difference in single-threaded performance, which is what limits KSP.

That's not how it works. Windows, or any other OS, constantly balances the load across all available cores. During normal use you should never see one core at 100% with the others at 0%. And 1 core is not the same thing as 1 thread, but that's a different discussion.

No problem. It's useful to know where the potential failure points are.

Are you using something to load directly into a saved game, without going through the regular load menu and the space center scene? Don't do that. Many, many things expect the space center to come up first and be loaded properly, if it doesn't things don't get initialized properly. In this case it's causing problems when CapCom tries to load the stock Mission Control Center scene texture atlas. I can change it so that this doesn't cause a total failure, instead it will show grey buttons on the top right. But in general those load-skipping plugins shouldn't be used outside of mod development.

Do you have the full log file? It doesn't look like an agency problem, it looks more like a problem in assigning the accept/decline/cancel buttons on the top right. Does this happen only with one contract? What does the window look like while it's happening?

Any idea why this doesn't evaluate properly: DATA { type = double diffModifier2 = Prestige() == Trivial ? 0 : Prestige() == Significant ? 10 : 20 } When a contract is trivial it comes out right, with 0, but either significant or exceptional both come out with 20. I've tried it is part of a DATA node or within a PARAMETER node, neither seems to work. CONTRACT_TYPE { name = SCAN_Biome title = Do a Biome Scan of @/targetBody2 group = ScanSatOfficial agent = SCAN: Scientific Committee on Advanced Navigation topic = Science subject = Kerbal motivation = Scanning notes = Scanning can take place while the vessel is not loaded. synopsis = Perform a MultiSpectral scan of @/targetBody2 completedMessage = Stunning, through the advances with this scanner we have identified several different biomes for further study. minExpiry = 1 maxExpiry = 7 deadline = Random(500, 1000) cancellable = true declinable = true autoAccept = false targetBody = @/targetBody2 // Contract rewards rewardScience = 0 rewardReputation = 1 rewardFunds = Random(40000, 60000.0) failureReputation = 1 failureFunds = Random(1, 10000.0) advanceFunds = Random(1, 10000.0) DATA { type = CelestialBody requiredValue = true uniqueValue = true targetBody2 = Prestige() == Trivial ? @ScanSatOfficial:p1Bodies.Random() : Prestige() == Significant ? @ScanSatOfficial:p2Bodies.Random() : @ScanSatOfficial:p3Bodies.Random() } DATA { type = double diffModifier2 = Prestige() == Trivial ? 0 : Prestige() == Significant ? 10 : 20 scanRequired2 = 75 + @diffModifier2 minScan2 = 74.9 + @diffModifier2 } PARAMETER { name = SCANsatCoverage type = SCANsatCoverage targetBody = @/targetBody2 coverage = @/scanRequired2 scanType = Biome } REQUIREMENT { name = SCANsatCoverage type = SCANsatCoverage targetBody = @/targetBody2 minCoverage = 0.0 maxCoverage = @/minScan2 scanType = Biome } REQUIREMENT { name = PartUnlocked type = PartUnlocked part = SCANsat_Scanner24 } }

The only real comparison that I can think of is with the city builder/murderous dictator simulator Tropico (if you haven't played Tropico you should go play it now, it's great). The game simulates each citizen, where they work, live, go to school, who their family is etc..., and it's all very CPU dependent. On the PC there is a limit of around 2000 people per island (there are ways to increase this, but you will always run into CPU performance problems at some point), but on the XBox version the population cap was reduced to something like 500-600. The game was otherwise the same, but limited to much smaller cities. Without any mods I would expect KSP to work fine on consoles, just with some similar kind of part limit, or maybe just with terrible performance above a certain point. It doesn't seem like it should be that hard to get RAM usage down, cut most of the textures down by 1/4 and you would probably be close to the Wii U's 1GB limit, or put a little effort into cleaning up all of the wasteful texture usage and get the same effect with less of a drop in quality; the other consoles shouldn't have a problem with that.

You check the discussion in the last few pages if you just want the M700 to handle everything. Or you can attach high-resolution MKS resource scanners to something else using the Module Manager config included with SCANsat as a template. As for the other resources being scanned it's hard to say without knowing what other parts you have and what scanners they might add. DMagic Orbital Science adds several SCANsat resource scanners, which could be responsible for those readings.

What are you using to scan with? SCANsat attaches the required modules to the MKS antenna, but otherwise most resources are only covered by the M700, which gives results only to the nearest whole number.

On that subject, how about a simple API with something like: is location x scanned for resource y, and scan location x for resource y.

Portrait Stats v6.0 is out; get it on Kerbal Stuff. It fixes a compatibility issue with Deep Freeze and RPM (thanks JPLRepo), adds a brief timer when exiting map view (to prevent the portraits from sliding in under the labels) and adds 2 digits to the current experience level. I would also add 2 digits to the experience shown for each entry in the flight/career logs, but those are generated using a stock method and I don't really want to rewrite that myself.

Will do, and it's already done for the next SCANsat update. Oh yeah, I put in a bunch of those.

Update preview time. There isn't much being added for the next update, but there are a few long neglected things that are being added. RPM panels are getting some much needed love. The 4 buttons along the left side of the standard MFD's can new be used for resource overlays and anomaly/waypoint markers. I've also decreased the resolution of the RPM maps, the texture dimensions have been reduced by half, this allows the maps to generate much faster. There is a noticeable difference in quality, but really only when you zoom in fairly close. You can control the map size (and the resource overlay quality) in the RPM configs for each panel. For now these values will have to be in Module Manager patches for the standard and ALCOR MFDs. I've also made it so the non-full screen maps, like the left-hand display in the ALCOR pod don't spend so much time rendering the part of the map that is covered up by a black overlay. Also this: Biome maps work fairly well here, and the display readout gives the current biome for each vessel on the map. There are several other minor changes: slope readouts on the big/zoom map, some changes to the color management window, and some other small things. Most of the changes are behind the scenes and result in lower RAM usage and less disruptive planetary overlay generation.

I think in general you can just use a single diffuse texture, and make the emissive texture very small. With some care in where the emissive part of the model is placed in the UV map you can get away with something much smaller than the color texture. Something like a 512 color map and a 128 or 64 emissive, for instance. Once you get down to that size you're talking about a few dozen kbs. It's probably easier to spend time finding RAM savings in more low-hanging fruit, like having 15 or so fuel tanks share 1 big texture (which could still accommodate multiple styles).

Thanks for that. I'll add these in for the next version.

The Steam hardware survey probably isn't a completely accurate representation of PC's, even less so for KSP people, but I'm not aware of any other large scale survey like it, and I can't see any reason why the distribution for KSP players would be drastically different. That said, the survey shows about 50% nVidia and 50% other. So it's not unreasonable to think that nVidia users might be in the minority. On the other hand, as one of the few games that show a significant benefit to being run on Linux, and given AMD's miserable Linux performance, the user base might skew more towards nVidia than the general Steam population. I'm using a GTX 750 Ti, which is great as a low power (doesn't require an extra cable), small form-factor card.

I'm not too sure about stock resource config settings. You might want to ask RoverDude about those. I think there might a problem with such high dispersal values, otherwise it seems like it should provide only very little Plutonium outside of Kerbin.

Yep, that can be added. Possibly Module Manager, it is required for all resource scanning. If you want the M700 to be used for all high resolution resources, at least those you've shown, just set "sensorType = 1162624" (the value that you have is 256 less, so I'm assuming that you want stock ore scanning there as well, since you have the display module included). That will give high resolution values for all of those resources, though it won't affect the narrow-band scanner requirements, so you can turn that option off if you want. I'm not positive about those two config values, I think variance adjusts how much separate biomes differ in resource abundance, and dispersal affects how much the resource abundance varies within each biome. All I know for sure is that there used to be a bug in the Karbonite config where its dispersal value was set to 0; this caused there to be no variance within each biome.

Well there is plenty of room for that. Just take a look at the Squad parts folder. It's full of 512 and 1k textures with minimal detail, full size emissive textures, nearly identical fuel tank textures, and so, so many non-square textures. Anyway, I'm looking forward to what you come up with.

You should be able to get 0.90 from Steam. Go to your Steam library -> right-click on KSP -> Properties -> Betas tab -> Select the Previous version. I think this will give you 0.90, though it might give you 1.0.2, or 1.0, you'll have to try it. It would be nice if they included all previous versions there. Edit: Too slow.