Waz

Sounds like a NetKAN/CKAN bug, because the .version file has: "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 4, "PATCH": 0 }, You'd have to ask the NetKAN maintainers. I'm no CKAN expert though, so I'm happy to accept a patch to the .version file. Hmm... unless they've started scraping it from CurseForge instead - I decided to upload this release there too since many people use it for mod discovery, and they only just added 1.4.0 as a version option. Hehe... the vanished @rbray89 is the original author, I'm just maintaining it since I like playing KSP with SVE. If you want to fund my coding, buy WazHack :-)

All I can say is give it a try. I maintain the mod, but I've always recommended configs besides the samples ones.

The basic idea was storms: instead of the whole half-sphere on this side of the planet, just an arc big enough for the storm. I haven't actually done anything with it though, so it may not be adequate. Volumetric clouds are the expensive things and they are just around the camera.

@Galileo is 100% correct - it sounded like a plea for an update to me. Nevertheless, at the time, I was half way through rebuilding the shaders with the correct Unity version and with a few other minor fixes it all appears to be working. Note that this new release adds an "arc" parameter - allows you to only put clouds in a section of a sphere, instead of having to render the whole sphere. It was just something I was half working on but couldn't find much use for, and it adds complexity in positioning of the section so I didn't pursue it. But it's in now, for good or bad.

KSP version?

Not without also affecting it in other views. The same could be said about looking at Earth from space, and NASA cannot tweak any Earth.cfg file. The in-game solution would be to use Scansat or the commnet scanner thing.

Did you also change the texture references in the cfg file in the CityLights directory you copied? BTW, the BoulderCo city lights are pretty blurry and blocky. Have you seen the far cooler ones in SVE?

No. Is it a big deal? I deliberately only enabled it on the KSC screen, as I agree - toolbar clutter is a problem when you're trying to fly a craft.

You've apparently never gone back to KSC to find it completely submerged at night with no buildings visible. It's not "breaking", but nor would it be "breaking" for Scatterer to not work at all, since it's entirely visual. It's a bug and should, eventually, be fixed. If I had to guess, I'd say that the sphere of the ocean is slightly behind or in front of Kerbin in its orbit, but I haven't looked at the code so it's purely a guess based on similar bugs I've seen in EVE.

I've seen github temporarily block downloads if I try to get a lot of stuff in parallel (eg. a big update via CKAN). Just wait and try again.

Nope, the clouds are a custom EVE-specific system, with a shader that gets the color/alpha of the particle from the main/detail texture directly - meaning that no matter if there are clouds there or not, you pay to "draw" all the completely transparent particles.

I'm not sure what you mean by "modern Unity shaders". The various shaders in EVE are the same as any other shader, just rather sophisticated. If you mean PBR or Surface shaders, I don't see how what EVE does would benefit from using any of Unity's PBR or Surface shader infrastructure (which are still just regular shaders, they just have chunks relevant to PBR pre-packaged).

Unfortunately, EVE doesn't even use Unity particles to draw the clouds (another reason they are slow). I'm thinking the only reasonable path forward on that would be to deprecate the old system and add an all-new system. I'm not sure I have the guts to attempt that though.

A bit late to this, but the whole POINT of OPM, I think, is to force you to use non-Hohmann transfers, just as NASA did with New Horizons mission to Pluto. I just visited Plock and landed, in 6 years.

Okay, try out this package. It adds an "arc" variable to the clouds. If you set it to anything other than 360, a different codepath will be used and only the given number of degrees will be meshed. Normally, the clouds are rendered on a subdivided half-isosphere that faces the camera. With this code, it's rendered on a UVsphere, and that mesh is rotated along with the texture. I feel we'll need another set of parameters to rotate the mesh around and the texture around with it, to allow a storm say to wander around the surface while itself spinning on its axis - I don't really know, I'm no content artist :-) https://1drv.ms/u/s!Ah0aNuGsTYhahH6FE9n8971ygI3Z

Such that it wasn't a sphere but rather 6 domes? Sure. That would also improve performance as the auroras wouldn't be drawn all over the planet. For a UVsphere it would also be useful to have ones that just cover the poles (or wherever they are rotated to) - good for auroras or for localized storms. If someone wants to test this wort of thing, I'm more than happy to do builds that implement various possibilities.

Good question. I don't know enough about KSP modding to know how inter-mod API calls can work. If you can find out how to call into EVE code, I can help you work out what it is you need to call for a specific task.

I haven't even downloaded KSP 1.3.1, let alone had time to play it, let alone have time to do whatever might be needed to make EVE work. Have you tried just installing it and seeing if it works?

Technically, an operating system shutdown cannot be caused by a user-space program like KSP. Shutdowns are almost always caused by either: Faulty drivers, especially videocard drivers Operating system bugs, often as a result of running low on RAM Hardware faults, especially RAM

EVE uses KSP's Sun.Instance variable, then either the Light component on that or the Sun.Instance.scaledSunLight private variable (hacks access via reflection). There is no way currently to specify a different star, but really there should not need to be - whatever Kopernicus is doing EVE should be doing too. Unfortunately, I know very little about Kopernicus, so I think it would have to be a contrib patch from someone who does. Either that or wait until I get around to playing with multiple stars and so get a burning desire to fix it myself ;-).

It seems to ignore Tourists aggresively. I put in a Tourist, save, then Revert (because I accidentally killed him), and it goes back to shoving Jeb in the seat.

Isn't that part of the challenge? The New Horizons trip to Pluto would take 50 years if they had used a Hohmann transfer.

Yes, clouds are definitely not the way to achieve this. The correct way would be a PQS City with a particle system. I've never modded for Kopernicus or KerbinSide, so don't know the feasibility of that.

The volumetrics clouds are entirely determined by the main texture. Unfortunately, this means same-expensive fully-transparent particles everywhere on the planet. The _DistFadeVert value determines the "popping in" distance (it should be set such that they fade in, not pop in), though I don't have a procedure other than trial and error for coming up with the appropriate value. BTW, the clipping-into-ground that you showed earlier and which @Galileo correctly noted as "Normal" should be fixable by adding depth-buffer-based softness to the particles (InvFade), but I haven't looked into it yet as shown here: Another cool option would be PQS clouds layer shapes (eg. following the land, 3D 2D layers, etc.). Feasibility TBD, but the clouds layers could be made into a PQS mesh.

The first value of the clouds area parameter is the radius; default 24km. Note that increasing it spreads out the clouds, so you usually need to either increase the second area value (integer number of subdivisions), or the size of the particles.