Jump to content

DMagic

Members
  • Posts

    4,167
  • Joined

  • Last visited

Reputation

4,282 Excellent

Profile Information

  • About me
    Capsule Communicator

Recent Profile Visitors

22,358 profile views
  1. The orange color readout on the bottom of the map indicates that you haven't scanned the Mun with the anomaly scanner at the position if the mouse cursor over the map. Keep in mind that the anomaly scanners require the surface to be in daylight during scanning. You can turn off this requirement in the settings menu if you don't want to deal with it.
  2. If it needs updating I will do so, but I haven't seen any problems yet. Do you have some planet packs or planet rescale packs installed? It looks like the scan status indicators on the small map are solid orange, which generally indicates being too low or too high. The SCAN menu part of the right click menu should indicate what is going on.
  3. Yes, that's the general pattern. The high resolution scanners mostly have lower fov than their lower resolution counterparts.
  4. @linuxgurugamer I commented on Github about it. FOV is a bit convoluted, but basically the scanning map is a 360*180 array of the whole number lat/long coordinates for the surface. The FOV defines how many whole number degrees around the vessel that will be scanned. https://github.com/S-C-A-N/SCANsat/blob/release/SCANsat/SCANcontroller.cs#L2539-L2611
  5. No they are saying this mod isn't supported anymore and won't work with newer versions of KAS. The Breaking Ground expansion provides a set of parts that are more or less the same as these (but without some of the hassle), so there isn't much of a point updating and supporting this mod.
  6. SCANsat version 20.4 is out; get it on Space Dock. This version prevents the overlay window from opening when it shouldn't.
  7. The reappearing overlay window will need a hotfix. Should be out in a few days.
  8. Version 20.3 is out; get it on Space Dock. This update fixes some issues with the big map data not being updated, drawing visual maps of the new gas giants, along with a few other bugs and issues related to resources, and some missing localization fields. It also includes some adjustments of part masses. It also includes new UI features related to resource overlays including small resource overlay color legends on the big map, zoom map, and planet overlay control window. The big map and overlay control window also feature quick tools to adjust the low concentration cutoff for resource overlays and a shortcut to the color settings for the current resource. There is a new resource setting option to hide resources in the UI ("Hide Unused Resources" in the Resource Settings tab of the Settings window) for planets that don't have any of that resource (this is not generally an issue with stock KSP resources). For instance, if there is a resource config that sets the Mun to have 0 Ore, then all of the resource selection menus will hide Ore for the Mun. This can keep the UI from getting cluttered with useless fields when using multiple resources. When this option is enabled the unused resources will always be hidden in the UI, regardless of whether you have scanned for resources on the planet. Since this could be considered a kind of cheat, you can disable this option. When disabled the unused resources will still be hidden, but only after scanning with either the low or high-resolution resource scanner to beyond the Scanning Threshold Level that can be set when stock resource scanning is disabled (you can disable stock resource scanning, change the threshold level, then re-enable stock resource scanning if you want to change this in the UI). There is also a new field in the settings file to disable visual maps. This could be useful for people having performance and crashing issues with SCANsat v20.x. If disabling visual maps solves the issue then it is a good sign that there are memory problems, as the visual map feature can consume a significant amount of memory. This field can be found in: GameData/SCANsat/PluginData/Settings.cfg. The file may not be present until you run KSP at least once with SCANsat installed. The field to change should be at the bottom of the list: VisibleMapsActive, set this to "VisibleMapsActive = False" to disable visual maps. There is no in-game method to change this setting.
  9. Update for the map data issues should be out next week. Just had an endless series of minor issues that I've found with the new update that have delayed things. @omG?! The old part models won't be replaced. Any active vessels or craft files will still use the old models. The models and scanners are all new parts, most with significant difference in size and shape, so they can't really be a direct replacement. Regarding problems with RO and maybe other planet packs. I'm thinking this may be a memory issue related to the new visual maps. An option to disable them might at least be useful for troubleshooting purposes.
  10. Slope is one of those tricky things that can get pretty complicated. It's highly localized and there are many different ways of calculating the value and reporting the value. SCANsat just asks KSP for the terrain height at a few points surrounding the center point, I think something like 5m distance. This is a little bit expensive to calculate, but not really significant in the scheme of things. (This is for the little instrument data window, the slope map is another matter, and is generally far less accurate). I think Engineer looks at the angle of the actual surface geometry relative to a flat surface. This requires that the terrain geometry (this could have changed at some point) is drawn, which means it will only work close to the surface. But it is fairly cheap to do and should give a precise value for a given point.
  11. @Alex33212 I spent a long time trying to get this to work a few years ago. I remember discussing it with JPLRepo around the time ResearchBodies was updated with a similar feature. But for SCANsat I kept on running into two problems: Altering the visible maps like this required making lots of copies of the textures (of potentially several planets that could be in view at the same time) then altering them, which was memory intensive (maybe this isn't as important anymore). And a significant amount of the visible detail on a planet comes from the normal map. You can basically wipe out the main color map (shrink it something absurd, like 64*64 pixels) and with an untouched normal map some planets wouldn't look that much different. The problem is that normal maps don't do well with seams, so if you have a body that is partially scanned, then you have a partial normal map, with a big seam at the border of the scanned area, so it looked terrible. Maybe I'll look into it again when I finish with this update.
  12. @RealKerbal3x Besides scanning characteristics (max scanning altitude, scanning fov) the two higher tech versions also scan for anomalies. Part mass is definitely something that can be adjusted. @MAFman It looks like the new Jool shader is quite a bit more complicated than the normal planet shaders. I can get pretty decent results with a simple fix: It's not as good as the real thing (Jool now has 5 8k * 4k textures making up its visible surface ), but not terrible either. The sun has a different set of problems, though I think it would be reasonable to assume that cameras meant to image a normal planet wouldn't be able to map the sun, so maybe I'll leave that alone. @Kepler452b It should work fine, I've tested in 1.8.1 while trying to track down the performance problems some people have seen in heavily modded installs of KSP (without any success in repeating those problems) and it seems to work fine. Also, lots of fixes and improvements are coming to the resource overlays in the next version: New resource overlay legends and quick adjustment tools (low right of the big map, and bottom of the overlay window), along with some changes to make handling installs with lots of resources a little easier.
  13. @One eyed Smile @TaintedLion Does this problem happen with Kopernicus? I've seen something like it before, it is related to how Kopernicus unloads the height maps for bodies that aren't nearby. SCANsat forces it to load when a map is being drawn, but I think there are some cases where it doesn't always work right. Switching the map to another body, if one is available, will usually fix the problem. @RealKerbal3x Hi res scans always "overwrite" low res scans when the map is being drawn. The low res scanner still functions, though, for the purposes of science and contracts. You can see the low res scan progress in the new big map scanning coverage indicators.
  14. 1. Still there, just like the image indicates, it's only available when stock scanning is not disabled. 2. A vessel with a MechJeb module with the landing guidance function enabled. 3. Resource Biome Lock toggled on means the biomes must be scanned from the surface for full accuracy. 4. All scanning means all scanning, there is no distinction between background vessel scanning and active vessel scanning. All scanning is performed through a single function, disabling this option will turn off that function.
×
×
  • Create New...