Jump to content

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


Recommended Posts

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

9tRzH4a.png

It's not as good as the real thing (Jool now has 5 8k * 4k textures making up its visible surface :confused:), 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. :D

 

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

yiFST8B.png

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.

 

Link to post
Share on other sites

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 by Alex33212
Link to post
Share on other sites

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

Link to post
Share on other sites
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

pApj8DH.png

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
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

Link to post
Share on other sites
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

MTktieN.png

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

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

 

Link to post
Share on other sites
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 by Daniel Prates
Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...