Observe

I just updated to new version (scatterer-0.0320b) and my sky turned very, very blue. Is there some way to tone this down? It's never been so bright in previous versions. Also, the ocean seems to be gone entirely. I'm running with RSSVE/RSS in case that makes a difference. Thank you.

Thanks. I'll give that a shot.

New version of RSSVE for 1.3? Where is it may I ask?

Problem solved. Cause was my own stupidity trying to use a savegame from KSP 1.2. I'll just have to start a new game and then copy whatever flags and waypoints that I don't want to lose. My apologies for taking time. Thanks.

Certainly. I thought I'd just throw it out there in case of some well-known solution I was unaware of. I can see this is not the case. This is a new KSP installation, so it's easy for me to remove the few mods I have thus far and see if I can solve by process of elimination in case some other mod is causing the trouble. I will get back with you. Thanks.

I noticed that too, but that's the way it is in the file. Besides, I tried adding closing brackets and still the loading error. Thanks.

I have just updated to KSP 1.3, and installed the various 1.3 compatible USI modules. I am getting this error on loading: 1 error related to GameData/UmbraSpaceIndustries/MKS/Patches/StockTweaks.cfg The above error goes away, if I edit the indicated file by removing the second-to-last section: @PART[FuelCell*]:AFTER[SQUAD] { @MODULE { OUTPUT_RESOURCE { ResourceName = Water Ratio = #$../INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]]/Ratio$ @Ratio += #$../INPUT_RESOURCE:HAS[#ResourceName[Oxidizer]]/Ratio$ @Ratio *= 0.25 DumpExcess = true } } I have no idea what impact this has. Any suggestions? Thanks.

Running KSP 1.3 with any ScanSat versions from 17.6 through 17.9. Problem: Big Map won't open in Tracking Station or any other map view. Small Map opens, but zoom doesn't work. As such, I can't even select which body I want displayed. Any suggestions? Thanks.

For those attempting to run RSSVE with KSP 1.3. I have good success with the following installation: KSP 1.3 RSS v12.0 for KSP 1.2.2 Scatterer version 0.0300 Environmental Visual Enhancements 1.2.2-1 RSSVE v1.2.2-RC3 for KSP 1.2.2

If you want to make your own flight plans, put your code in FlightPlans.cfg. Create the file if it doesn't exist. You can use the code from DefaultFlightPlans.cfg for reference. The biggest challenge is coming up with the latitude/longitude coordinates. The way I sometimes do that, is using Waypoint Manager, I fly my desired path, setting waypoints as I go. Then, by examining my savegame file, I can see the coordinates that I need to feed into my FlightPlans.cfg file. Another way, is once you have a satisfactory path at one location, you can mathematically convert to any other lat/long location coordinates. I use a spreadsheet for doing this.

Part of the challenge, is even with a 16k (pixel resolution) image we are still working with an 8 bit (color depth) greyscale heightmap with values from 0 (lowest elevation) to 255 (highest elevation) to represent altitude. Earth elevation, ranges from about -11km below sea-level to about 8.8km (Mt. Everest) above sea-level. This means that over half of the elevation range is underwater. If realistic underwater altitude is important, we would have to use at least half of our dynamic range for underwater details that are not seen by most players. Given that KSP is mainly for flying in the atmosphere or in space, it is understandable that we would want most of our heightmap range (0-255) used for above sea-level details.

@AlmostNASA. The 'heightmap' is EarthHeight.dds found in the RSS - Textures/PluginData folder. This is the image used to derive elevation data. If you look at that file, you will see that the Mariana Trench is there. However, as you pointed out, underwater altitude is not accurately represented. This is something I have corrected in my custom image, but I am not quite yet ready to release it.

@bsooner77 Is this a custom flight-path that you created? Unless you've already passed it, your craft should first fly toward the IAF = true waypoint, proceed toward to any additional waypoints that aren't marked true (for IAF, FAF, RW or Stop) and then it will head to FAF, RW and finally Stop. At some point, I had the same problem as you are describing. I don't remember exactly what I had to do, but I think I had incorrect Waypoints specified in the config. Either that, or I had some other autopilot running that caused conflict.

@AlmostNASA I haven't checked specifically, but the heightmap does include underwater elevation; so the trench should be there.

@sDaZe For me, heightmap is the most important texture for RSS; because that is the one that determines how accurately the land/water division is - which affects the shape of the coastline for continents, islands, lakes etc. I'm not too concerned about ground texture as such. I just want to fly to some island like Hawaii or anywhere on Earth, and have the terrain be a reasonable facsimile of how it should look. The approach I'm taking, is I've downloaded the highest resolution images from NASA Visible Earth. These come in a sequence that need to be "stitched" together, resized, rotated, etc. For some of that, I'm using ImageMagick command-line processing, because the images are too large for working with in PhotoShop etc. Anyway, the result is 16k images that while still not super detailed, are noticeably better than 8k images. As I mentioned elsewhere, it is possible to mix resolutions - using 16k for the heightmap and 8k size for all the others. This minimizes impact on memory and graphics resources, while still presenting higher detail.

@Phineas Freak I apologize if this is the wrong place, but I'm not sure were best to post. As you know, I presented some of my texture related findings in your RSVE thread, but I thought here is more appropriate, since it is more general to RSS and not specific to RSVE. As one who enjoys designing and flying aircraft and spaceplanes, I am interested in higher resolution Earth terrain. There are some issues with underwater sediment shelves protruding above water. Original 8K textures (note the arrows showing areas where there should no land): Some of that can be corrected via VertexHeightMap offset, or by adjusting the image as shown here: Now at least the islands are separated and the sediment shelf is below water as it should be. Reference Google image: Next, I created 16k images. While not perfect, the detail is improved as would be expected: Personally, I think it would be worth having 16k images available for planet Earth at least. I'll likely continue working on this for my own use. I haven't made any mods for KSP - so I don't know what the procedure would be for creating an add-on for 16k Earth images. Anyway, I thought my findings might be of interest to someone in future. Thanks.

Another approach with textures, is mixing resolution. For example, it is possible to use a 16k heightmap along with 8k color and bump maps. I am running some tests along those lines, and results are encouraging. While 16k color doesn't improve things much, 16k heightmap on the other hand does add noticeable height detail. This hybrid resolution method, uses far less memory and other demands than full 16k.

Here are my results from lowering the underwater sediment shelf slightly. In this example, I'm using a location over the Channel Islands off the coast and a little South from Vandenberg Air Force Base. Original EarthHeight.dds (note the arrows showing areas where there should no land): Modified EarthHeight.dds (note correct separation between islands and no land jutting out from mainland) Reference Google image: I think my modified heightmap image improves island and coastline rendition and it doesn't affect altitude above sea level. As you say @Phineas Freak, it's a matter of finding a middle-ground compromise to achieve the less-than-perfect best of all worlds. Thank you EDIT: Here is my modified EarthHeight.dds image.

An example of what I do, is using Waypoint Manager mod, I manually fly my desired flight plan, setting waypoints for IAF, FAF, RW and Stop. Then, I edit the KramaxAutoPilot FlightPlans.cfg file, using the latitude, longitude and altitudes recorded for those waypoint. I reference a savegame to find the waypoint coordinates for easy copy/paste. Thus, I end up with something like this: FlightPlan { planet = Earth name = OSR East ILS description = Land OSR East Approach WayPoints { WayPoint { Vertical = true IAF = true lat = 32.990155 lon = -106.7 alt = 2000 name = OSRE IAF } WayPoint { Vertical = true lat = 32.990155 lon = -106.83445 alt = 1500 name = OSRE 01 } WayPoint { Vertical = true FAF = true lat = 32.990155 lon = -106.90 alt = 500 name = OSRE FAF } WayPoint { Vertical = true RW = true lat = 32.990155 lon = -106.9644109 alt = 150 name = OSRE RW } WayPoint { Vertical = true Stop = true lat = 32.990155 lon = -106.989284 alt = 0 name = OSRE RW STOP } } } In my case, those values work for East runway approach. I do similar for West approach. Then, using the in-game UI, I can load my new " OSR East ILS" flight plan. It works like a charm! Similarly, any flight route could be prescribed.

@Phineas Freak Thank you for the reference thread re. 16k limitation. Good to know. I was messing around with 16k images myself a couple of weeks ago, but wasn't able to achieve anything satisfactory. Regarding the ocean/land transition I mentioned previously, I know realize much of this problem is related to the sediment shelf (continental and insular) present in EarthHeight.dds. This prevents a clean transition from land to water; often resulting in a flickering effect. Frequently, this sediment shelf is rendered above sea level - causing islands to join together or become severely distorted. Currently, I am running an experiment with slightly lowering the sediment shelves in EarthHeight and the results look promising. I found a high-res TIF elevation image that has no bathymetry (water depth) and using it as a mask, I slightly lower the EarthHeight sediment elevation. This gives me a much nicer and more accurate transition from land to water. I'll post my results here if conclusive.

One thing I'd love to see addressed, is sharper division between water and land. Sometimes I want to position Kerbal Space Center on an island, but the flickering effect between water and land often destroys immersion. I realize this is beyond the scope of your mod - and indeed probably beyond anything RSS can do. I think this is probably just the nature of the beast when spreading an image map texture over such a large area. Even with 8192 image size, one pixel can cover a fairly large area of the terrain and coastlines are not always distinct. Oh well, just wishful thinking on my part. Anyway, thank you for this great mod!

Perhaps only my preference, but I really don't like the way EarthSurface (and EarthRock) texture "smears" the surface and the tiling is not very seamless, so I removed it in my config file. Looks much better without. Also, that texture was obscuring the somewhat more natural coloring from the standard Earth materials. Thank you.

Excellent! Glad you were able to get it working.

@nitropic I don't know the exact links so I've uploaded the relevant files here: AnyCPU-EVE-Release RVE-KSP-1.0.4-Linux64 scatterer-0.0256 The above are working (clouds, city lights) in my 1.2.1 game version.

@jd284 If what you are experiencing is the same as I have, there are two ways I've found to remedy: Plant a flag near your base and select it whenever you want to change location to your base. In my case, it is the object that I target to move to, that suffers the worst from this physics bounce (or whatever) on load. The other way, is sometimes in the savegame, objects are referenced with a negative altitude (below ground). Editing the savegame to give the object a positive altitude (one meter for example), will reduce or eliminate the load-bounce. I think this is a KSP bug, rather than RSS or Kopernicus. On the other hand, perhaps your situation is entirely different.