[1.10.1] SCANsat [v20.4] -- Real Scanning, Real Science, at Warp Speed! [September 9, 2020]

[MAFman]

I noticed that I can't make a visual map of Jool or the Sun. Is that supposed to happen?

[Beetlecat]

Probably because there's no "reachable" surface to scan?

[Kepler452b]

Does the newest version v20.2 work in ksp 1.8?

 

[DMagic]

@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.

 

[Starseeker]

Something that'd be neat to see is a mod that blurs out the surface of bodies in map view based on their distance from Kerbin (and completely greys out the unobservable parts of bodies, like the far side of the Mun), and SCANSat visual scans make the map view more detailed.

(Sorry if that's a bit off-topic ^^;)

Edited August 11, 2020 by Alex33212

[DMagic]

@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. 

[Starseeker]

2 hours ago, DMagic said:

@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. 

Ah yeah, fair enough!
Though, regarding the normal map issue - perhaps some sort of "smoothing" at the edges? Google Maps does something similar for differing-quality terrain data on the ocean floor:

Spoiler

 

[NateDaBeast]

Noob question but I guess I've forgotten how to use the mod:

Why does my probe just stop scanning at one point? It's not a Electric Charge problem.

[Starseeker]

@NateDaBeast Probably because that side's in darkness; visual, biome, and resource scanners all only operate on the lit side of bodies now.

Though, if it's not in darkness, then something wierd's probably going on.

Edited August 13, 2020 by Alex33212

[NateDaBeast]

1 minute ago, Alex33212 said:

@NateDaBeast Probably because that side's in darkness; visual, biome, and resource scanners all only operate on the lit side of bodies now.

Though, if it's not in darkness, then something wierd's probably going on.

Yea I checked and at some points it is in darkness but typically is not and I made sure it wasn't for that screenshot.

[Starseeker]

@NateDaBeast Gotcha, yeah, then it's something I don't know about, sorry ^^;

[NateDaBeast]

Just now, Alex33212 said:

@NateDaBeast Gotcha, yeah, then it's something I don't know about, sorry ^^;

I did notice that in the smaller version for viewing I can see the biomes and stuff mostly, just odd how it stops at that point for me on the big view.

[Starseeker]

Just now, NateDaBeast said:

I did notice that in the smaller version for viewing I can see the biomes and stuff mostly, just odd how it stops at that point for me on the big view.

Ah, I think I've run into this: select another body to view the maps for (even if you don't have any generated for it), then back to Kerbin, and it should update

[NateDaBeast]

6 minutes ago, Alex33212 said:

Ah, I think I've run into this: select another body to view the maps for (even if you don't have any generated for it), then back to Kerbin, and it should update

For whatever reason this is what I see, so I can't switch

[Starseeker]

2 minutes ago, NateDaBeast said:

For whatever reason this is what I see, so I can't switch

Ah, hm...

[NateDaBeast]

Just now, Alex33212 said:

Ah, hm...

I figured it out, just needed to send a probe to another body first, I guess you cant view other planets till you visit them. And your trick fixed my issue once I could select another planet. Thanks man!

[Starseeker]

no problem!

[FieryBull]

Am I the only one who can only extend/retract SCANsat parts while in the VAB scene? In the flight scene I can't. There also doesn't seem to be actions available to extend/retract. This is in KSP 1.10 using SCANsat version 20.2

[RealKerbal3x]

13 minutes ago, FieryBull said:

Am I the only one who can only extend/retract SCANsat parts while in the VAB scene? In the flight scene I can't. There also doesn't seem to be actions available to extend/retract. This is in KSP 1.10 using SCANsat version 20.2

In the flight scene the parts automatically extend when you start a scan and retract when you stop it. There's no actual extend/retract options in flight because that's tied to the status of the scan.

[FieryBull]

10 hours ago, RealKerbal3x said:

In the flight scene the parts automatically extend when you start a scan and retract when you stop it. There's no actual extend/retract options in flight because that's tied to the status of the scan.

That explains it. Thank you.

[Crixomix]

https://imgur.com/a/2Rswyt3

can anyone explain what's going on here? I'm so confused on how this is failing to scan in a tiny little strip. It's lit by daylight as well.

 

I'm also having weird issues where faster timewarp depletes electric charge compared to slower timewarp, but that's not this mod's fault of course.

[DerekL1963]

7 hours ago, Crixomix said:

I'm so confused on how this is failing to scan in a tiny little strip. It's lit by daylight as well.

Try loading a different planetary body then reload the "glitched" one and if there's still a problem.

[Brigadier]

KSP 1.8.1, JNSQ v0.9.0, SCANSat v20.2, Win10

As others have noted above, the big map wasn't updating as it should but the small map was.  I placed two satellites - one altimetry, one biome - in Kerbin orbit at or very close to optimal altitude.  Both had sufficient EC and were on the daylight side.  The small map showed the scan results, the big map didn't despite refreshes.  I could not load another body since I hadn't advanced far enough in the tech tree to get there and if I hyperedit there I would have borked my Strategia conditions.  I don't wish to do that.

I altered the colour pallet and reviewed all of the other options.  Turned on were: Show Ground Tracks, Legend Tooltips, MechJeb Target Selection, WIndow ToolTips, Daylight Scanners, All Scanning Active, Resource Biome Lock, Require Narrowband.  All the remainder are turned off.  I thought I had a screenshot but when I checked, it was incomplete.

BUT...I quit and restarted the game,  The big map was working as advertised.

Player log, KSP log, persistence file from before the restart are all here.

Hoping the additional information is useful.

 

[Daniel Prates]

On 8/16/2020 at 3:35 PM, Crixomix said:

faster timewarp depletes electric charge compared to slower timewarp

This is not an "issue" really, not a mod issue anyway. It's how KSP monitors things in the background as you timewarp. It affects all mods and the base game as well. In short, doubling to 2x times does not make things consume two times faster, it can go slower or faster than what would be correct. Things can go weird in time compression. 

Let me explain better. Suppose a craft with many parts, heavily modded (doesn't matter which mod). You build it so it generates exactly 100 ec per minute, and place things that drain exactly 100 ec per minute. Without timewarp it will stand in equilibrium, right? And should too if you timewarp. However what happens is that, in some TWs (16x for instance) you will see a deficit and batteries will start to drain, then you go to 36x and you see a superavit where batteries start to charge. 

Insofar as I know, there is no 'fix' for this. Its just the game handling badly too much information, potencialized by timewarp.

Edited August 19, 2020 by Daniel Prates

[Maravone]

Hello, I'm playing KSP 1.8.1 with RSS/RO and RP-1. Twice I've tried to upgrade to SCANsat v20 and twice I suffered from the same issue: huge memory leak as I try to load any save, to the point where it simply fails to load one, freezing the game.
Between both times I reinstalled everything and the problem persisted. I tried to actually load with a barebones RSS/RO install, and still suffered a memory leak that froze the game completely.

I've noticed others here in the forum have come across the same or very similar problems while using RSS/RO, and I know that there are multiple other people using RSS/RO that have come across with the same problem from talking with them in the RO/RP-1 discord.
Unlike someone else who pointed out that the issue could be RemoteTech, I am not using RemoteTech. If I revert to SCANsat v18.x the problem goes away, so its definitely specific to v20.