DMagic

A quick check of Amazon and Newegg shows only overpriced and refurbished CPUs for the 1155. So it's a bit hard to recommend buying something that can only be found overpriced or used. If you can find a reputable place (like HardForum, but you can't just jump in and start buying from there, which is probably why it remains rebutable) to buy from, then a used CPU isn't so bad, but I would be nervous about buying hardware from something like Ebay. DDR4 isn't really that expensive, it's pretty easy to find 8GB for $60-70, which isn't much more than DDR3. I'm not sure about motherboards, but there is probably no way to spend less than $350-400 or so for a CPU/MB/RAM combo, even if you wait a few months for the non-K CPUs and some more mid-range MBs.

First off, did you try out the resource additions using the stock system? Make sure you can get planetary resources to show up with stock resource scans first, just to check that the configs are working. Thorium and Alumina are already SCANsat resources, so nothing needs to be added, but your Plutonium config won't work. The SCANtype 524288 is already taken, it is a special value used by the M700 scanner that covers all valid planetary resources (I should probably update the SCANresources file to clarify that); you'll have to use the next value, 1048576. Next, don't change the M700 sensorType in the Module Manager config, as I said, it uses a special sensor type. To add high-resolution scanner modules to a new or existing scanner you can either add separate MM configs for each resource type, or change the sensorType for an existing high-resolution resource scanner. For instance, if you want to add the high-resolution scanners to the MKS antenna just change the sensorType to 1162368, that should cover all three new resources and the standard MKS resources. You'll also want to add the resource display modules to the MKS antenna: MODULE { name = SCANresourceDisplay sensorType = 2048 ResourceName = Thorium } etc...

Experience isn't granted until you recover the craft (unless you're using Magico's Field Experience) and Portrait Stats reflects that. The experience field will only show experience that has already been granted (the events that gave that experience should show up in the "Career Log" section of the tooltip). The second part of the experience field, under the slash, is the amount needed to advance to the next level (I think 2, 8, 16, 32, and 64 are required for each level). It doesn't show the actual level, that is handled by the star icons. I see now that I should probably include the first two digits after the decimal though for the current experience. I had thought those values were always whole numbers, but apparently they aren't.

Uh, erm, so, like this: Though I can see why it would also be nice not to have deal with any kind of connecting on EVA.

I tried this out on the launch pad and on Minmus in a stock install. Triggering the error was easy and I setup a proper bug report. I also tried with DMOS installed, in neither case could I get any of the other weirdness to happen, the frozen portraits, control lock-outs, etc... Thanks, I'll add these in. Trial and error. I'm sure there is some simple way of going from the part orientation in Unity to how they should be carried on a Kerbal. But I didn't want to go through the Unity scenes for each part, and a lot of them are rotated in the configs, so I just did a lot of database reloading; it was fun.

Derp... well, it's intended to work as a range for the colors, I just implemented it wrong. It's an easy fix though, thanks for pointing it out. I'll include these in the next update, or is it easier to just do all of the scaling in the MODEL nodes?

Solar panels can have a significant impact. Each one has to be constantly tracking their position relative to the sun and how much power they should be generating. Stick a hundred or so (as compared to a hundred other parts) on an otherwise small craft and you'll a huge difference.

It seems dumb, but maybe get rid of the last part of the KerbalStuff URL. You don't need to include the mod name, just the number.

There are no stock scanning contracts. This one comes from the SCANsat lite pack. The M700 doesn't scan for Ore, it gives a low resolution scan for all resources; this is, internally, a different resource, so it won't count for the contract. To get the high resolution Ore scan and complete the contract you have to use the Narrow-Band scanner. The only way to complete the contract without the Narrow-Band scanner would be to turn the Instant scan back on (and disable stock scanning off) and complete the stock resource scan, that would fill in the map for all resources. But that also kind of defeats the purpose of using SCANsat scanning. The "Requires Narrow Band Scanner" option is there to limit the zoom map resource overlays, planetary overlay tooltips, and instruments window resource readouts. With that option turned on you'll need a Narrow-Band scanner on board or in orbit to use those features, it doesn't have any effect on the contract or on actual scanning. I should probably see about incorporating the SCANsat lite contract pack into the standard SCANsat package, rather than relying on a separate download. I would probably also modify the contracts a bit, and make it ask for the M700 resource scan, not the high resolution scan.

Not to get into an argument about Macs, but there is no way you can replicate that iMac for half of the price. The very purpose of the retina iMac is for that giant 5K screen. The only standalone 5K screen that I know of is a Dell monitor that costs more than $2000 (more than the base price of the retina iMac; though choosing the base model is kind of insane and the markups for the upgrades are absurd). While the screen you listed has a nice refresh rate it is vastly inferior in every other way. As to the OP, no, the AMD card won't make any difference for the physics calculations. Neither will an nVidia card. Everything is handled on the CPU. I'm not sure about how well that GPU will handle KSP at 5K, but you can always try running it at a lower resolution in a window, or use scaling.

Actually it doesn't, I guess I just put it in there for clarity. That does complicate things. So adding OPM (or any other Kopernicus) configs beforehand is probably a bad idea (using MM in general might actually be a bad idea for config files like this, it isn't really designed for it). Luckily, the values can be set in-game pretty easily. When KSP first loads, SCANsat reads all of the terrain configs from the file at the main menu. It searches for planets that match the index number and assigns each terrain config to its matching planet. If there is no planet with that index number then it will just drop that config (there is a potential bug here that needs to be fixed), if the index matches a different planet than what is intended then you will end up with mismatches. If there is no config for a planet in your game it won't be a problem. It won't even come up until you've visited that planet at least once. At that point SCANsat will see that there is no terrain config for that planet and it will assign one. After a config is assigned for a planet you can edit and save it to the config file using the color management window. If the numbers get mixed up at some later date this will cause mismatches, but I hope there is some system in place to avoid this. Planet index values are used all over the place, most notably in contracts when assigning a target planet.

I watched most of the video; it was a little hard to tell in some cases if the boarding bug was being triggered every time the portrait freezing/other weirdness happened. From the logs I think that it did, which would make the most sense. I'll have to go out Minmus and stumble around a bit while printing out the collisions list to confirm, but I think that those times you climb onto the lander and sort of stumble may trigger the effect, floating around might trigger it too, it's hard to say.

You wouldn't, those collision messages have to be manually printed out with a mod. I'm not sure exactly which movements will trigger all of the collisions. But I just tested it out in a stock install with nothing but a Kerbal and a MkI pod on the pad. I had to take a running dive off the launch pad to fall down, after climbing back up and boarding the vessel it triggered the error. So there is definitely a stock issue here. All of the other effects may be related to the broken Kerbal OnDestroy method, or they might not be. This kind of error when a part is being destroyed or unloaded can have very strange effects. The launch clamp bug, where the launch clamps appear floating in the air about 6000m above ground after launching is, I think, related to this same kind of thing.

There isn't really anything needed. You could use Module Manager (I think) to add some default terrain color configs for the OPM planets. Add another "Item" like that shown below to the SCANsat_Altimetry node in the SCANcolors.cfg file. SCANsat_Altimetry { Item { name = Mun index = 2 minHeightRange = -500 maxHeightRange = 7000 clampHeight = Null paletteName = RdGy paletteSize = 11 paletteReverse = True paletteDiscrete = False } } The relevant values are the index (the flight globals index), the name, the min and max height range (this sets the upper and lower bounds for the terrain maps, useful for planets with extreme variations in altitude), and maybe some of the palette options, though you would have to be careful about getting the names right if you use anything other than Default. All of these values can also be set in-game with the SCANsat color management window. I'm not sure if Kopernicus has any means for editing this, but there is a value somewhere for setting when the resource overlay textures will become visible. Otherwise there isn't much to do about it.

I'm guessing that particular contract parameter is active in the editor for some reason, so it's seeing that the vessel isn't moving. Doing something like that for other parameters, checking if the required parts or experiments are on board would be tricky. It would probably require a specific method for each parameter.

No, it's all separate from those difficulty sliders. You could use it for separating building upgrade costs (I think Kerbal hiring costs are also affected) from contract penalties. Just leave the stock slider at 100% (or whatever value), then change the global contract funds and/or rep penalty sliders to something higher. The science gains from vessels returns and experiments also aren't affected by this mods sliders. You could do something similar to what is described above though, use the stock science slider to set values for experiments and adjust the contract sliders from this mod accordingly. And all of the stock difficulty settings can be changed in your save file after starting. They are all found near the very top of the file, I think the values aren't given as percentages, so if you have science returns at 60% it will show as 0.6 in the save file.

The pictures clear things up. What's happening is that before scanning the biome the overlay just takes the average ore concentration for that biome, which seems to be above whatever 70% of the max value is. After scanning the biome, the overlay calculates the exact ore concentration for a certain point, which is apparently below the cutoff. The problem arises because of the interpolation I was talking about before. Actually calculating the resource value for each position on the planet would be prohibitively slow. So the overlay makes a texture, calculates resource values for certain pixels, then interpolates in between. So the pixel within the crater that is being used for the resource calculation is below the cutoff, but it only appears this way after scanning the surface, because the average value for that biome is above the cutoff. You can actually see the interpolation at work if you look carefully. Close to the center of the blob in the crater there is a slightly brighter spot. That is the actual location that the overlay is using to calculate the resource abundance. So at that exact location (which might be very difficult to land at, each pixel on the global map represents probably several kilometers) the concentration is below the cutoff, and nothing appears at all in the crater. You can try editing the MapResolution and InterpolationLevel fields in the GameData/Squad/Resources/Overlay.cfg file (the current overlay type you have on is listed as SOLID, the others being LINES and DOTS) . Reducing the interpolation level and/or increasing the map resolution (use 512 or 1024) will probably allow you to see resources on the overlay in the crater. It will also probably be slower to generate, causing a bit of a hiccup when you push the overlay button.

It might, though probably not that much. I can see how you would get from that debug message on entering a vessel to having weird problems with the crew and other things. But I don't see how that initial bug could be triggered. Edit: OK, I seem think I've isolated where the bug starts. The error message refers a UnityEngine.Collider List in the current Part instance: InvalidOperationException: Collection was modified; enumeration operation may not execute. at System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].VerifyState () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].MoveNext () [0x00000] in <filename unknown>:0 at Part.OnDestroy () [0x00000] in <filename unknown>:0 Trying to modify elements of a list (deleting or adding elements) while cycling through each element of a list is a pretty well known way to break something, and it's easy to avoid, so I'm not sure why Squad has such a thing in their Part.OnDestroy method. Luckily, there appears to be only one such list in Part: currentCollisions. By printing out the contents of currentCollisions (the Vessel class has a method for this, Vessel.printCollisions()) for each part I can see where problems will arise. I don't think there is any issue with modifying a list like this when there is only one element, it's only when you have more than one that issues arise. When I print out the values for a vessel on the launch pad I get: [LOG 19:32:52.383] Collision between mk1pod (Untitled Space Craft)... [LOG 19:32:52.384] ...and LP_barsAlpha in localSpace Which seems reasonable, the LP_barsAlpha would seem to be the bars on the launchpad. Here's another one with an EVA Kerbal standing next to a vessel with her head clipping through a part. [LOG 19:27:51.785] Collision between kerbalEVAfemale (Mira Kerman)... [LOG 19:27:51.786] ...and LP_ground in localSpace [LOG 19:27:51.786] Collision between kerbalEVAfemale (Mira Kerman)... [LOG 19:27:51.787] ...and node_collider in fuelTankSmallFlat This is off of the launch pad, so there is a different ground collider. Now when I jump around things get interesting: [LOG 19:29:49.021] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:49.022] ...and LP_barsAlpha in localSpace [LOG 19:29:53.077] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.077] ...and bn_l_knee_b01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.078] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.078] ...and handCollider_l in kerbalEVA (Bob Kerman) [LOG 19:29:53.079] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.079] ...and bn_r_hip01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.080] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.080] ...and handCollider_r in kerbalEVA (Bob Kerman) [LOG 19:29:53.081] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.081] ...and bn_spA01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.082] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.082] ...and bn_l_hip01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.083] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.083] ...and bn_r_knee_b01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.717] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.718] ...and bn_l_hip01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.718] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.719] ...and bn_spA01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.719] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.720] ...and handCollider_l in kerbalEVA (Bob Kerman) [LOG 19:29:53.720] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.721] ...and handCollider_r in kerbalEVA (Bob Kerman) [LOG 19:29:53.722] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.722] ...and bn_r_hip01 in kerbalEVA (Bob Kerman) [LOG 19:29:53.723] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:53.723] ...and bn_l_knee_b01 in kerbalEVA (Bob Kerman) [LOG 19:29:58.130] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:58.131] ...and bn_l_knee_b01 in kerbalEVA (Bob Kerman) [LOG 19:29:58.131] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:58.132] ...and handCollider_l in kerbalEVA (Bob Kerman) [LOG 19:29:58.132] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:58.133] ...and bn_l_hip01 in kerbalEVA (Bob Kerman) [LOG 19:29:58.133] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:58.134] ...and bn_spA01 in kerbalEVA (Bob Kerman) [LOG 19:29:58.134] Collision between kerbalEVA (Bob Kerman)... [LOG 19:29:58.135] ...and LP_main in localSpace [LOG 19:30:02.999] Collision between kerbalEVA (Bob Kerman)... [LOG 19:30:03.000] ...and bn_l_knee_b01 in kerbalEVA (Bob Kerman) [LOG 19:30:03.000] Collision between kerbalEVA (Bob Kerman)... [LOG 19:30:03.001] ...and handCollider_l in kerbalEVA (Bob Kerman) [LOG 19:30:03.001] Collision between kerbalEVA (Bob Kerman)... [LOG 19:30:03.002] ...and bn_l_hip01 in kerbalEVA (Bob Kerman) [LOG 19:30:03.003] Collision between kerbalEVA (Bob Kerman)... [LOG 19:30:03.003] ...and bn_spA01 in kerbalEVA (Bob Kerman) [LOG 19:30:03.004] Collision between kerbalEVA (Bob Kerman)... [LOG 19:30:03.004] ...and collider in mk1pod Bob is standing on the launch pad bars, with his helmet next to mk1 pod. All of the other values seem to be between body parts clipping through each other during the jump. Most importantly is that these collider messages persist even after Bob is back on the ground. So now the collider list has lots of entries. Trying to board the vessel again triggers the error message: [EXC 19:30:04.461] InvalidOperationException: Collection was modified; enumeration operation may not execute. System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].VerifyState () System.Collections.Generic.List`1+Enumerator[UnityEngine.Collider].MoveNext () Part.OnDestroy () And interestingly, trying to print out the collider list again from the mk1 pod no longer works, I get this error (I stuck a button in one of SCANsat's windows to print out the values, that's why all of the SCANsat references are in this message): [LOG 19:30:35.382] Collision between mk1pod (Untitled Space Craft)... [LOG 19:30:35.383] ...and LP_barsAlpha in localSpace [LOG 19:30:35.383] Collision between mk1pod... [EXC 19:30:35.384] NullReferenceException Vessel.printCollisions () SCANsat.SCAN_UI.SCANoverlayController.resourceSettings (Int32 id) SCANsat.SCAN_UI.SCANoverlayController.DrawWindow (Int32 id) SCANsat.SCAN_Platform.SCAN_MBW.DrawWindowInternal (Int32 id) UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) I think what it's trying to do is print out values from the EVA Kerbal collider which didn't get properly destroyed when I boarded the vessel and interrupted the OnDestroy method. I can reliably replicate the error by just exiting the vessel, jumping around a bit (not every jump seems to trigger all of the collisions), then boarding the vessel again. I assume something similar happens while jetting around on EVA on the Mun or Minmus. Sometime I'll try reporting an official bug for this after making sure that it happens in a stock install. Edit 2: Actually the surest way to replicate it seems to be to fall over before boarding. I can do this easily by jump up into part of the vessel, but any way you fall over should work.

Portrait Stats version 5.0 is out; get it on Kerbal Stuff. It adds more info to the tooltips and fixes the lazy black icon outline drawing method I was using before, it also changes the colors a bit.

Probably, I haven't looked at tweakscale for a long time. I can see the debug log error when boarding sometimes, but I've never been able to reproduce all of the other weird things that you see happening after.

Maybe you should add some screenshots, it could clear things up. As far as I know the cutoff just takes anything below (cutoff% * maxAbundance%) and sets it to 0. Whether that max value is directly from the config, or is taken by looking through the save-specific value for each biome of that planet, I'm not sure. So the map overlay will show only values above the cutoff. The problem here is that the map overlay is not accurate. It uses interpolation to fill in most of the map, you can see or change these settings in one of the config files in the Squad/Resources folder. Only a handful of locations are actually checked for their resource abundance. This means that what you see on the map overlay may not reflect the actual resource abundance at all. This can be easily seen on Kerbin; all of Kerbin's ocean have their ore abundance forced to 0%, which can easily be confirmed with the narrow-band scanner or from the surface. But the map overlay can show a lot of ore present even fairly far away from the shore or isolated islands, this is worse with the line or blob maps.

The max values for all of the planets from the configs is 15%. I'm not entirely sure if that's the value used by the cutoff, but the average value definitely isn't.

I assume these are used for some mods? Do they have any stock purpose? In any event, courage, stupidity, badassery, and experience amounts are all things that should be added to the tooltips. The first three can probably go in the trait tooltip (since it's always shown, regardless of game type) and the experience amount (current / experience for next level) can go in the star icon tooltip. And yes, maybe I'll make the wrench yellow.

Yeah, I know about the animation thing; it's just a result of not taking experiment resets into account when setting up the sample animations (multiple animations on the same part can get complicated). That shouldn't have any other effect. I still don't have any clue about that bug, I've been looking into how the external data collection works and there might be something worth checking out, but I think it's just a bit of redundant code.