VonFrank

Are the steps to modify scatterer to function with RSS in 1.2 the same as they were in older versions? I seem to be having problems getting atmospheres to show up on the RSS bodies using the same process described on the OP.

I read earlier that Scatterer is intentionally disabled in the Tracking Station. I was wondering if there was a setting to have it enabled there as well (the atmospheric scattering, the sunflares, and the reduced ambient space lighting). The Tracking Station can be a cool place to take a visual tour of the solar system and it would be great to enable the enhanced visual settings while in it.

Well, we may not have solved my problem, but we do at least have some documentation down on these issues for other people who might have these questions in the future. Thanks for all the help rbray!

Thanks for the reply. I am using the latest version of RSS with a bunch of extra moons I've added on my own to fill in a lot of missing celestial objects. Saturn, however, and all of its moons are default in RSS so that has nothing to do with my additions. Here is the shadow config file: EVE_SHADOWS { OBJECT { body = Earth caster = Moon } OBJECT { body = Moon caster = Earth } OBJECT { body = Mars caster = Phobos caster = Deimos } OBJECT { body = Phobos caster = Mars caster = Deimos } OBJECT { body = Deimos caster = Mars caster = Phobos } OBJECT { body = Jupiter caster = Io caster = Europa caster = Ganymede caster = Callisto } OBJECT { body = Io caster = Jupiter caster = Europa caster = Ganymede caster = Callisto } OBJECT { body = Europa caster = Jupiter caster = Io caster = Ganymede caster = Callisto } OBJECT { body = Ganymede caster = Jupiter caster = Io caster = Europa caster = Callisto } OBJECT { body = Callisto caster = Jupiter caster = Io caster = Europa caster = Ganymede } OBJECT { body = Saturn caster = Mimas caster = Enceladus caster = Tethys caster = Dione caster = Rhea caster = Titan caster = Iapetus } OBJECT { body = Mimas caster = Saturn caster = Enceladus caster = Tethys caster = Dione caster = Rhea caster = Titan caster = Iapetus } OBJECT { body = Enceladus caster = Saturn caster = Mimas caster = Tethys caster = Dione caster = Rhea caster = Titan caster = Iapetus } OBJECT { body = Tethys caster = Saturn caster = Mimas caster = Enceladus caster = Dione caster = Rhea caster = Titan caster = Iapetus } OBJECT { body = Dione caster = Saturn caster = Mimas caster = Enceladus caster = Tethys caster = Rhea caster = Titan caster = Iapetus } OBJECT { body = Rhea caster = Saturn caster = Mimas caster = Enceladus caster = Tethys caster = Dione caster = Titan caster = Iapetus } OBJECT { body = Titan caster = Saturn caster = Mimas caster = Enceladus caster = Tethys caster = Dione caster = Rhea caster = Iapetus } OBJECT { body = Iapetus caster = Saturn caster = Mimas caster = Enceladus caster = Tethys caster = Dione caster = Rhea caster = Titan } OBJECT { body = Uranus caster = Miranda caster = Ariel caster = Umbriel caster = Titania caster = Oberon } OBJECT { body = Miranda caster = Uranus caster = Ariel caster = Umbriel caster = Titania caster = Oberon } OBJECT { body = Ariel caster = Uranus caster = Miranda caster = Umbriel caster = Titania caster = Oberon } OBJECT { body = Umbriel caster = Uranus caster = Miranda caster = Ariel caster = Titania caster = Oberon } OBJECT { body = Titania caster = Uranus caster = Miranda caster = Ariel caster = Umbriel caster = Oberon } OBJECT { body = Oberon caster = Uranus caster = Miranda caster = Ariel caster = Umbriel caster = Titania } OBJECT { body = Neptune caster = Proteus caster = Triton caster = Nereid } OBJECT { body = Proteus caster = Neptune caster = Triton caster = Nereid } OBJECT { body = Triton caster = Neptune caster = Proteus caster = Nereid } OBJECT { body = Nereid caster = Neptune caster = Proteus caster = Triton } OBJECT { body = Pluto caster = Charon } OBJECT { body = Charon caster = Pluto } OBJECT { body = Eris caster = Dysnomia } OBJECT { body = Dysnomia caster = Eris } } Upon further testing of my issue, it seems that only the Saturn and Uranus systems are having the issue of Shadows not functioning. Neptune, Pluto, and Eris all work as intended. Could it be an issue with having more than 5 bodies (1 main body and 4 casters) in the group of shadows? For the penumbra, I see where you're coming from and that explanation is sound, but there is still a bit of an issue that is probably what caused me to think there was absolutely no penumbra whatsoever on objects that should at least still have a bit of one. The Jupiter system, for example, is one which has a varied selection of moon sizes, distances, and apparent angular diameters to test things on. I took a screencap of a closeup of Ganymede's shadow on Jupiter and found this: You can see that there is indeed a penumbra, but it is wobbly and undefined. In a non-static image, it shifts and warbles so much that your eyes tend to only notice the solid black area and it makes it seem that there is no penumbra. This issue seems to scale with distance from the light source. Triton's shadow on Neptune is far worse due to it being at an extreme distance from the sun, yet if Neptune is hyper-edited to have an orbit as close as Mercury, and Triton is proportionally given a closer orbit to Neptune as to compensate for the Sun's larger apparent diameter at that distance, the Penumbra becomes solid and well defined.

I'm a little curious about how the celestial shadows function works. With the most recent versions of EVE and RSS, I notice that eclipse shadows on Jupiter seem to work properly when the config file is modified appropriately, but any planet farther than that fails to render the shadows. Is there a limit to the calculated distance from the sun for the celestial shadows to work properly? Also, I've noticed that many shadows are comprised of 100% umbra and no visible penumbra at all. Every shadow (regardless of relative size and proximity) should have at least some penumbra, but not all should have an umbra. So is this an issue somehow with RSS conflicting, or is it a feature of realism not possible at the moment?

Anyone else getting an issue where attempting to apply clouds to a planet created with Kopernicus causes an error that freezes the game when clicking on the tracking station? Is there currently an incompatibility between EVE and Kopernicus in 1.1?

OK, several things: 1. While using Environmental Visual Enhancements (not EVE overhaul) the sky flickers darker and lighter when ON THE SURFACE of Earth. This is not the same z-fighting problem when viewing a planet form far away with EVE and only occurs in RSS as far as I can tell. 2. Using RSS + FAR but WITHOUT Deadly Re-entry or any other heating mods, I'm still having issues with overheating. The most troublesome now seems to be the explosion of engines once they leave the atmosphere due to rapid overheating. They also do not seem to cool down over time once in space. Intentional or not? 3. With the above mentioned combination of mods, re-entry heat still baffles me. I can now easily survive a re-entry along an appropriate descent trajectory, but the atmospheric effects seem very intense even though there is little effect on the heatshields.

*Sigh* This doesn't answer my question at all. I fully realize that KSP is not nearly as realistic as many members of the community would like to think it is, but that's not what I'm asking. I know that re-entry is a very tricky thing IRL, but thats still not what I'm asking. All I want to know is if there is a setting to modify the game's heat settings so that the heatshields which were configured to survive the slow speeds of the stock Kerbin re-entry can be usable on RSS. I already have FAR installed, and I know the physics behind how to properly and safely enter an atmosphere. The fact remains that with stock settings, the heat accumulation is far too great for what is should be.

Is there a setting in the game's physics file that can be tweaked to allow the game's stock heat shields and/or the Procedural Parts heat shield to survive the 7km/s+ re-entry speeds present in RSS? As it stands now, the PP heat shield barely lasts down to 100km altitude before it lets my MK-2 pod explode.

What's the specific formatting of the .DDS textures used by RSS? I'm trying to add Vesta, and it shows up in game, but the scaled space view of it is all white. Also, the texture file itself is much larger than those for all other included planets & moons (10.6mb vs 1.33mb). The texture files are the same resolution, so it not that. Are there specific parameters the image must be exported with in order for it to be recognized by the game? Is this a question that is better to ask over at the Kopernicus thread? I'm using GIMP, by the way. Thanks.

I have 1024x512 .PNG maps for Miranda, Ariel, Umbriel, Titania, and Oberon all with no gaps. But I only have the COLOR maps, not HEIGHT. As far as I am aware, there are no height maps available anywhere for those moons.

I didn't expect it to work flawlessly, but just so other people know, there seem to be issues with this and KSP 1.0. The game loads fine and you can get to the KSC menu, but with a replaced skybox attempting to click on the tracking center freezes the game. There's probably other issues as well, but that's all I've found so far.

And just how did you do that? I've also noticed that the center of lift on the Ranger is way near the back while the center of lift on the Lander is near the front. Perhaps it has something to do with that?

Something strange I've noticed: I'm playing on an install with NEAR and the Ranger seems to always want to flip backwards while flying. In fact, it flies backwards much better than forwards, strangely enough. Is there something that can be flipped to reverse this? For example, if the game thinks the Ranger body is like a capsule, which are designed to fall through the atmosphere with the bottom down, then perhaps the game thinks the back of the ranger is the bottom and therefore it travels more smoothly through the atmosphere backwards.

Okay. that explains why many of the planets & moons in RSS were resulting in the scanner giving the same swath width for all of them. It's because they were mostly all over 600km in diameter, meaning the multiplier was always 1.0. Since this is the case, is it possible to modify the code to reference Kerbin's radius (whatever that may be after mods have altered it) instead of a fixed 600,000m?

Thanks for the quick reply. Ok, so what I get from your explanation is, Swath width is calculated as follows: Swath Width in degrees = sqrt(Kerbin radius in km (600) / orbiting body radius in km) * fov value in config So for Earth in RSS, the formula for the SAR sensor would be: SW = sqrt(600/6371)*2 SW = 0.61 degrees Please correct me if I'm wrong in some way, because I am attempting to set the fov values on the scanners to represent values for real life remote sensing satellites for function in RSS. Thanks.

A couple of questions: First, correct me if I'm wrong, but the way the mod is coded now means that the swath width of each scanner (as noted by the fov in the part configs) represents some kind of percentage instead of a width in km. This means that on a large planet, you will get a large swath width and on a small planet you get a swath that is the same size proportionally, but much smaller in reality on the surface. In other words, the swath on Kerbin will be 3 times as wide as the swath on the Mun because Kerbin has 3 times the circumference. Is there a way to make the swath width a specific fixed value (like 15km wide for stock KSP scales) so that every planet will have realistic scaling for how long it would take to map the surface. After all, a large object should take much, much longer. Second, is there a way to modify the minimum and maximum altitude settings for the colormaps of planet scans. I ask because on RSS many planets have terrain heights higher than the values that the mod limits the slider bar to. For example, Mars (Duna) is limited to 17,500m for the max value, yet Mars' terrain goes up past 29,000m. Overall, the mod is fantastic, but I was just curious about these things in particular.

I'm doing heightmap in the RSS config as well.... Hmm.... can you post the section of your config file with Ceres? I'd like to see the difference between yours and mine. I have over 30 more celestial objects that I would like to apply the correct heightmaps to.

I cant believe I've never noticed this before, but Earth's heightmap is vertically exaggerated by an approximate value of 2.0. Mount Everest, for example, sits at a little over 18k m above sea level, when it should only be at 8,830m. And it's not just there. Most of the Antarctic Ice shelf sits around 7k masl while it should only be around 2-3k or so. Is this only happening to me? Can anyone else confirm or deny this being a common glitch?

I have this problem too, yet very few others seem to have it. I'm trying to make Ceres in RSS using Mun as a template, and no matter what I do, the new heightmap I apply to Ceres overwites the heightmap of the Mun. And this happens even using the latest version of KopernicusTech.

Has there been any progress yet in fixing the way a ring's inclination is handled with respect to the parent planet and the moons around it? I made a post a while ago in this thread regarding the issue but no one commented on it in any way. My idea was to essentially get the rings to act as an orbiting object, with a modifiable longitude of ascending node so that they are always oriented in the same direction as the matching moons on a planet.

Something desperately needed IMO is the ability to set a LAN (longitude of ascending node) value to rings. The way rings work currently is alright if you want them to have no inclination whatsoever (take Sarnus and Urlum from the Outer Planets Mod for example), but if you want to have the rings on your planet inclined, things get a little bit more complicated. For example, trying to recreate Saturn with its ring inclination of approx 27 degrees means you need to lock the ring rotation, otherwise the rotation of the rings will wobble around with the rotation of the planet because of KSP's lack of an axial tilt system, which is, of course, unrealistic. However, while locking the ring rotation solves the problem of the silly looking ring wobble, it means that the rings are stuck at an arbitrary position that might not line up with the LAN angle of the planet's moons. See the following screenshots for an explanation of the problem: As you can see, an accurate representation of Uranus suffers from the same problem. What I suggest, is the ability to specify a specific Longitude of Ascending Node for the rings of a planet. This will make it possible to match the LAN value of the rings to the approximate LAN values of the planet's moons in order to line them up properly and ensure they are always lined up no matter what. What do you guys think about this? Is this even possible? If not, is there a way to get around the issue?

Well, even though I still cant figure out the heightmap issues, this still works great for what I'm trying to accomplish. I currently have a 40 planet/dwarf planet/moon solar system with this and RSS. Here's some pics I put on reddit a few days ago.

So then, for the moment, is it still better to use this AND RSS in order to replace the stock solar system with a realistic one? Because aside from the stock planets which are modified in RSS, I also want to add new planets & moons in order to create all of the celestial objects in our solar system that RSS does not include. I had this working fairly well with the previous versions of Kopernicus and Kittopia. The only issue was the override error with biome maps and heightmaps for Kopernicus planets. Has that been fixed?