DMagic

That may be, but the version that is actually linked to in the download section of the first post has out-of-date dependencies, so problems are to be expected.

Probes Plus seems to be including version 16 of DMSA (it crashes at ca_landv_cam_s1, which is the first part with a DMSA module), version 19 is the latest and works fine in KSP 1.3.0 and 1.3.1. https://github.com/DMagic1/DMModuleScienceAnimateGeneric/releases/tag/v0.19 That said, it still crashes for me in 1.3.1; the output log shows it failing at: PartLoader: Compiling Part 'Coatl Aerospace/ProbesPlus/Parts/Antenna/antenna_cone_toggle/antenna_cone_toggle' Which has a data transmitter and a FSmeshSwitch module, I think it's the first part with a FS module. Maybe the FS assembly is old, too?

@mkalaska It seems okay for 1.3.1. There were no changes that I'm aware of related to anything Orbital Science does, and it doesn't have the same issue that causes some mods to directly crash KSP. @1990eam Any planet pack should work fine. There will only be default science results since any custom planet requires custom science results text, but otherwise it will be fine.

Version 18.1 is out; get it on Space Dock. It has been updated for KSP 1.3.1, but should work on 1.3.0 (and v18 should work in 1.3.1). A few bugs have been fixed: the list of celestial bodies from the big map should work properly and show all scanned bodies, the narrow band scanner requirement should work correctly when more than one resource is loaded, and the BTDT should show some info about anomalies even if they haven't been scanned from orbit (also some potential platform-related issues with the BTDT display should be fixed). Terrain color palettes are now loaded from the GameData/SCANsat/Resource/SCANpalettes.cfg file. If for some reason the file is deleted or moved a new copy with all of the standard palettes will be generated. MM can be used to patch in new color palette definitions. The selection of color palettes from in-game works the same as before. @Jebs_SY I removed the MM patches for the ASET MFD panels because all of the relevant data seems to have been added to the ASET configs. But both before and after doing that all of the ASET MFD's worked fine for me. Maybe some other MM patch is causing problems, it doesn't seem likely, but I can't think of any reason why the panels would be affected in that way. @Tyko I didn't modify the waypoint selection system. I noticed that on the zoom map the waypoints seem to match up almost perfectly with the mouse icon tip, but on the big map they were off by about 10-20%. So I'm hesitant to add any offset since I think there might be some map size, map type, or maybe even screen resolution dependence on how much of a mismatch there is.

Probably tomorrow, the crash is because of the settings menu that Squad thoroughly broke for 1.3.1, it just requires a recompile. But I need to test a few other things to make sure nothing else is broken.

Basic DeltaV version 2.0 is out; get it on Space Dock. It is updated for KSP 1.3.1 and does not support KSP 1.3.0. It adds the readouts to the flight scene along with several options to restrict these readouts available in the stock difficulty settings panel. You can also display the readout only for the current stage. The readouts are only visible in the flight view, not the map view.

@wile1411 Do you mean like the progress nodes messages ("first orbit", "first launch", "speed record xxxm/s"), the things that show up in the toolbar messages window? For the actual progress nodes and whatever reward they give you can use either CapCom or Contracts Window +, both of which monitor and display that information. And since that data is persistent it's not just for the current scene. If other mods use that window to provide data then it wouldn't be picked up, just the stock progress messages. That information is very different from the screen messages, and while it's probably possible to just intercept it when it gets posted I probably won't go to the trouble of doing it.

@Tyko I see the waypoints being offset just a little, maybe 15-20% of the height of the waypoint icon, I think the actual mouse location just doesn't correspond exactly to where to the tip of the mouse pointer is. I can try to offset it a little to compensate.

@MOARdV @Jebs_SY I think the issue is that the ALCOR MFD's in question just haven't been added to SCANsat's list of MM patches. These non-standard screens require some changes to make sure the map is only drawn on the correct part of the screen. I'm updating SCANsat soon, so I can just add in or fix patches for any extra ALCOR MFD's.

@Tyko Once the waypoint is placed it's just a standard stock waypoint. Right-click on it (the actual waypoint, not the icon on the SCANsat map) and select delete. You can do this with any custom stock waypoint, like ones created in the KerbNet maps, or using the debug console (type /waypoint to create one at your current location, I think there are other commands for specifying location and for the KSC).

Basic Orbit and Maneuver Node Evolved have been updated for KSP 1.3.1. Maneuver Node Evolved is just a recompile for the difficulty panel settings. Basic Orbit fixes some bugs with the toolbar panel UI in KSP 1.3.1. A fix for Basic DeltaV will be coming soon (it has the same toolbar UI bugs), I just need to test a few more things since it is a much bigger update.

Lots of mods have been updated for KSP 1.3.1. Portrait Stats, Celestial Body Science Editor, and KerbNet Controller were simply recompiled because it's required that Squad breaks the difficulty settings panel on every update. EVA Struts and EVA Transfer were updated to fix some minor bugs causing the struts/fuel lines to look broken while a Kerbal is holding them. Science Relay was recompiled for 1.3.1 and has many new log message printed to the debug log. These concern the number of connected vessels detected when opening the science results window, lots of data about science transmissions and their success or failure, and more error messages. As for problems with CommNet Constellation, I never saw any crashes. If people continue having problems let me know and I can disable the vessel connection check when the other mod is detected (or try to figure out a better solution). Flexible Docking and One Window should be fine for KSP 1.3.1

@Jebs_SY Where do these MFD's come from (edit: okay, it probably comes from the mod this thread is for )? The MFDPatches.cfg file in the SCANsat/MM_Parts folder has patches for some of the ASET screens, but anything different would require a new patch. The patches basically define the button functions and the screen size. If you look at those patches you'll see startline and stopline fields. Those specify where on the screen the map is actually drawn, as opposed to the controls and other data, so I think the resource overlay is just being drawn from the bottom of the screen.

@Nils277 Is the purpose of getting the fallback fonts so that KSP can display all of the symbols used in the current language? UISkinManager.TMPFont should provide you with the font KSP is currently using. I'm not sure if it uses different fonts based on which language KSP is using, or if just has all of the fallback fonts assigned, it should be easy enough to check. And it might be simpler than running through all of the loaded fonts.

For reference, this is what the color palette configs look like (the fourth value in each group is the alpha channel and isn't strictly necessary to be added): SCAN_Palette_Config { PaletteTypes { Item { PaletteType = Fixed PaletteGroups { Item { PaletteName = blackForest Palettes { Item { Colors = 176,243,190,255|224,251,178,255|184,222,118,255|39,165,42,255|52,136,60,255|156,164,41,255|248,176,4,255|192,74,2,255|135,8,0,255|116,24,5,255|108,42,10,255|125,74,43,255|156,129,112,255|181,181,181,255|218,216,218,255 } } } } } Item { PaletteType = Sequential PaletteGroups { Item { PaletteName = OrRd Palettes { Item { Colors = 255,247,236,255|254,232,200,255|253,212,158,255|253,187,132,255|252,141,89,255|239,101,72,255|215,48,31,255|179,0,0,255|127,0,0,255 } Item { Colors = 255,247,236,255|254,232,200,255|253,212,158,255|253,187,132,255|252,141,89,255|239,101,72,255|215,48,31,255|153,0,0,255 } Item { Colors = 254,240,217,255|253,212,158,255|253,187,132,255|252,141,89,255|239,101,72,255|215,48,31,255|153,0,0,255 } } } } } } } If you want to add a palette with a fixed number of colors you just add another Item{} node under the Fixed type group. For palettes with variable number of colors you add it under one of the other groups. Module Manager patches can be used to manage this as well using the right syntax (I could probably change the syntax so that it uses the standard name = ... instead of PaletteType or PaletteName to make MM patches simpler).

KSP uses Unity's UI system, and it's easy to load asset bundles created through Unity. So you can create your UI entirely withing Unity, but it is sort of tricky. You can't import anything from KSP into the Unity editor, so all of your UI code has to be maintained separately from anything that touches KSP. So you can can make the UI (using either default style elements, like the sprites for buttons, toggles, windows, etc..., as placeholders, or you can generate your own, using the old Unity "Ghost" UI elements), write the code for buttons, assigning text, toggles, etc..., but then you have to go through some tedious work-arounds to actually communicate with KSP. And since you can't do anything with KSP in the Unity editor your UI will most likely not really work withing Unity. It really just depends on how much of your UI is dependent on KSP, and how you write the code to control the UI. It's very simple to create the shell for your UI entirely within Unity, but getting things actually working is going to require a lot of the same old, start, re-compile, restart, change the UI, restart, restart, restart...

@Geschosskopf There is a bug where the big map celestial body list only looks for primary planets (the ones that orbit the sun) that have been scanned by something with SCANsat, any amount of scanning should do, it just has to be enough to register it in the save file. It's possible the Kopernicus planets that add other stars, or do something funny to the sun will have problems beyond simply scanning the parent planet. The bug has been fixed for a long time, but I've been doing lots of other things and now I'm waiting for 1.3.1 (or really I'm waiting to see if a new power supply fixes my dead PC, since it decided to stop doing anything at all yesterday ). @drtedastro Any type of in-game editor for color palettes is unlikely, as that is more work than I'm willing to do for such a niche feature. But importing color palettes is simple. I've converted the old hard-coded system to read all of the palettes from a file in the SCANsat/Resources folder (if the file is missing it will generate a new one with all of the current palettes). You can just add in a new palette definition and it will show up in-game. For some reason I didn't commit the actual config file to the GitHub repo, but the rest of the code is all there (this also gave me a chance to root out the extremely messy and confusing old system of handing palettes in the code). https://github.com/DMagic1/SCANsat/blob/release/SCANsat/SCAN_Palettes/SCANPalette.cs Basically it just reads a list of RGB color values stored as a long entry in the config file. You can make simple, fixed color palettes (the config format is similar to this, but without the C# stuff) like the default SCANsat colors (used on Kerbin), or you can make variable length palette groups, where the same group has options for palettes of different lengths (like these).

@siderr It's possible that there is a language issue when using Russian, but I don't think so. It isn't supposed to work in Sandbox mode, the button might show up if you have already loaded a non-sandbox save, but otherwise the mod is disabled in Sandbox mode. Generally when the button doesn't show up in Career or Science mode it means that there are no valid vessels to connect to. The Science Relay settings (found in the stock difficulty settings panel) determine what a valid vessel is, and if CommNet is on you will need to have a connection to a vessel for it to show up.

@garwel CelestialBody.Orbit.ReferenceBody should give you what you need. Just check if it's null or the same as the celestial body in question to account for the sun.

@siderr Log files needed:

@Kilo60 I went back and actually looked at your screenshot. It's working exactly as it should. The name of the anomaly is MSL, its distance is 25.5m. The "No structures found" part is just an effect of this anomaly being different in some ways from others. I should probably change it to just leave that line blank if nothing is found for it.

@Gilph Slope maps are a real problem for SCANsat. The slope maps are basically the minimally acceptable accuracy for displaying slope information, they use very little data in calculating that information, and so they can't be relied upon too much. Generating more accurate slope data is a performance problem because of how the terrain data is obtained. The other slope readouts, the mouse-over for the map, and the data in the instruments panel, are much more accurate, they use a lot of data for a very localized position (8 points in a 5m grid around the center), but they only apply to either the center of the current pixel or the current vessel position. The problem with slope is that it is very highly localized. The slope for one area can be significantly different from that 20m away. So when you represent slope on a map each pixel could easily represent several km on the surface, so a low slope at the center of a given pixel doesn't really tell you much about the actual terrain. You could theoretically export a data set with more accurate slope information (or take the already available terrain height export data and do slope calculations yourself), but again, at a reasonable resolution you would only end up with only a very rough estimate of the slope at any given area. Zooming in very close to a location is the only real way to get any kind of accurate information about an area. But even then the standard terrain map (since the terrain colors are recalculated based on the local min and max terrain height) is basically as useful as the slope map.

@TheKurgan You would just need to target the right node: SCANSAT_SENSOR[SolarWind] { @name = GoldOre } That should work, I think. Renaming a node after using the name to locate should work fine.

@TheKurgan 500 shouldn't work right, 512 (2^9) should be okay, that's SolarWind, a KSPI resource, 64 (2^6), Kethane, should also work.

@TheKurgan Yes, you can replace any that you don't want (except for a few of the lower values that are reserved for standard SCANsat scans). @sh1pman I think I see the problem. There is just a bug where the narrow band scanner requirement only works for scanners with just one resource. So for stock, with just Ore it would work because the scanner type matches exactly. Whereas with MKS, with its 10 or so resources all on a single scanner, they don't match exactly, so it doesn't work. I have an update almost ready, it should fix this, along with some inconsistencies with how the anomaly scanners work, a few other bugs, and it makes some changes in how color palettes are defined. I'll probably wait for 1.3.1, just to make sure nothing breaks with that update.