Tekener

Let it snow, let it snow, let it snow!

Well, there is no water from Scatterer in your screenshot. What you see is the ocean ground texture, but no water at all, therefore no waves, no shadows, no reflections, ... Try reinstall Scatterer or reload the game (I had this once and a reload fixed it)

Oh, really? Interesting that they aren't. Patterns and textures should always be a resolution of a power of two in both directions to enable the gpu/cpu to do fast calculations on them. The used patterns must be resized internally to calculate the different distances. In a dds file the lower resolutions (always by a power of two) are also included to save the valuable time of this calculation process (Mip Mapping). However, if the resolutions are something like 1500 x 1500 this is not working correctly and in case the dds are not using such mipmaps combined with such an unusual resolution it can cause slowdowns. Don't know if it can be that extreme, but I could imagine there is a noticeable impact.

Yeah, when I provided my files to you and the public I mentioned that I got the old duststorms on Duna from @Astronomer working again, keeping the correct rotation aspect even over a long period of time. The cloud graphics is "his", the configs are redone and newly calculated by me. Similar goes to the atmo layers he introduced earlyer on when there was no scatterer, which I also mentioned. The atmo file is from his pack, the configs as for duna redone to better match usage with scatterer. Using a plain small graphics instead of a pattern for a nearly unvisible cloud layer would be his idea, and if I would have wanted to steal it I could have redone that graphics in a different resolution @Astronomer: It's great to see you back and I am sure nobody ever wanted to "steal" your work, we all tried hard to keep the things you invented alive - like the duststorms or the atmo layers.

Yeah, that's why I was thinking about the gradually fading by using different cloud setups. Changing them depending on time is more realistic then just "fly away". I would try it with this approach to take the possible transition notice into account: Cloud layer definitions would switch after a certain ingame time passed and only when the scene is entered, meaning the cloud definitions chnage when switching screens and players will not see the transition, e.g. going to the KSC and back to the ship, or maybe even when switching to the map and back. When players don't see the transition and the cloud layers are kind of fading into the next one the illusion would be nearly perfect. Would you like this better?

And how are things going? Do you think you can provide a working Eagle with the 1.2 release next week?

Of course switching the cloud patterns with a batch file when starting KSP is pretty simple, but there are still many players out there who have no clue of such a thing. I agree with Galileo that a good solution would be switching the cloud layer file from inside the game automatically, maybe switching them after 5 days of game time or something like that. The perfect solution would be to switch the usage of the cloud definitions rather than the cloud pattern files after a free to be defined number of game days. Then we could set up different cloud layers and even mixing several cloud patters, like this: Cloud setting 1: Cloud pattern 1 100% Cloud setting 2: Cloud pattern 1 66%, Cloud pattern 2 33% Cloud setting 3: Cloud pattern 1 33%, Cloud pattern 2 66% Cloud setting 4: Cloud pattern 2 100% Cloud setting 5: Cloud pattern 2 66%, Cloud pattern 3 33% ... Then there wouldn't even be a hard "cut" changing one pattern to another, but they fade over and with a hand full cloud pattern files we could create a large amount of cloud formations.

Don't get fooled, it is and will always stay the same cloud pattern. However it is not simply rotating but is getting disorted by the noise filter. But in the end the clouds will not change in any way and will always have the same pattern over and over. There is no way to have different patterns over land or sea for example.

Then, would you share the Eagle with the community or at least with us fans, please? I feel a bit sorry for @TheRagingIrishman that he already spent his time on something that already exits.

Wait, are you saying you have a working Space 1999 Eagle for the current and even upcoming 1.2 version of KSP? And yes, I guess one must have grewn up with this and Star Trek TOS to love this thing

Amazing, I can't wait to get the Eagle back in the sky - yeah! Keep up the great work!

No guarantee that this is working or the right one, but that's what I was able to find when searching the net before asking here to get it converted: http://tekener.com/KSP/Space_1999_Eagle_1.2.rar I hope that you can make this Eagle fly. Give him wings, mate!

I would prefer @Galileo and @Poodmund collaborate on this to prevent having two different Outer Planet Mods. I wouldn't want to decide which outer planet mod to take, because Galileo's temp planet looks super cool, but still I would like to keep the other OPM ones as well. And I'm sure the community wouldn't want to split up as well.

Cities will stay flat on the surface, it's just a texture. But one should never ever land on a city, this is not good See cities as areas with a "do not enter" sign Or have you ever heard of NASA landing Apollo in New York or the Space Shuttle in Miami?

Contrary to you behaving like Mr know-it-all and blaming people, I had the manner to ask Kowgan politely directly to explain the map because I had a similar issue. I wouldn't explain it to you if you would have come and insult my work because of lack of knowledge/dumbness. So I can only support Kowgan in not telling you. That one can't know all is normal, but then one would ask politly - or did you go to your teachers and tell them: "Guys, your material is bad, this is all wrong and you don't know what you do. Now tell me what is 1 + 1?" But since you haven't insulted me: Nowhere on the map it is indicated that the dV is measured from a circular Kerbol orbit! It is measured from an elliptical orbit around Kerbin (!!!) with a periapsis of 80 km and an apoapsis at the edge of the sphere of influence (SOI, about 84,000 km for Kerbin) - which you would see when being capable of reading the map and understand symbols. Going to another planet is based in this elliptical orbit when you add another dV amount being at the periapsis, when the ship is the fastest due to Kerbins gravity. Having the elliptical orbit already "pointing" in the direction you want to go (e.g. Duna) adding another 130 dv already brings your apoapsis into Duna's Kerbol orbit. When the timing it correct you will intercept Duna there without having to waste the fuel on a circulare Kerbol orbit. Adding another 510 dv (250 + 360) brings you into a circular Duna orbit without aerobreaking. When using aerobreaking the 360 can be skipped. So the velocitiy change you need from a circular 80 km Kerbin orbit to get into an elliptical Duna orbit for aerobreaking is about 1.350 km/s dV. Getting into a circular Kerbol orbit first and then to Duna needs about the double amount. The values are correct when you know how to read them. To get the right point of time and the right angle of acceleration for another planet when in Kerbin's orbit you need to use a transfer window planning tool like NASA is using it for all their missions, they don't fly by "best guess" or "let's first orbit the Sun and see where we want to go to then". Get the mod "Transfer Window Planner" (CKAN or here) to learn how fuel efficient interplanetary travel is working.

Maybe a stupid question, but why don't you use the private message function instead of flooding the thread? Just wondering

Well, I don't know what exactly is not woring for you and haven't looked at it in detail, but I can tell you that you must not touch/change the speed or the height of the cloud layers from my values as Berlin used them. I calculated the speed of the layers in relation of their hight and the size of the planet (Duna) they are on to make sure the different cloud layers don't "go off" by time, as they would be with your changed values in the 3 & 4 layer. Start by using Berlin's could.cfg and texture files moved to BoulderCo if you want to have it there. If this is working slowly alter the values you might want to have and see if one of them suddenly breaks the clouds. But as said: do not alter the height and speed values as otherwise you will have blured cloud layers after some years of game time.

I guess Berlin is using the same as me and the others: Photoshop - expensive but since I use it for work as well the best choice.

I can't help, it looks unnatural empty and artifical What was wrong with mine you liked the most so far but never published? (http://tekener.com/KSP/SkyBox.7z)

Just to be correct, I brought back the Duna duststorms and offered them Berlin to use in SVE So sure, feel free to use them, as they are based on Astronomers but working without diffusing over time now.

clouds.cfg Object "Kerbin-clouds1" Change _MainTex { value = BoulderCo/Atmosphere/Textures/fair type = CubeMap } to _MainTex { value = BoulderCo/Textures/cube type = AlphaCubeMap alphaMask = ALPHAMAP_A }

This is an old known issue of EVE with no fix yet vailable, same as the double drawn cities in Kerbin. Imagine, Pepe and Corga are the first bold Kerbals to dare landing on Minmus, just to figure out tourists are already there before

You can try mine, Berlin wanted to integrate it but then decidd to remove it completly: http://tekener.com/KSP/SkyBox.7z

I like it!

You can open the config with any texteditor, notepad, even word, as they are pure text files And Berlin surly did not got the aurora/shadow/clouds to "glow", "shine" or "emit light" as this is impossible. All that can be done might be to try having a green shadow on the ground texture of Kerbin, but that would be darker than the actual aurora texture and disappear at night, while what really makes an aurora is that it would be visible and glowing especially at night - but this can't be done.