Poodmund

Thanks for the heads up guys, I have updated all the links in the OP to the latest builds. On a side note, as far as I know this mod should work fine with the latest release builds of the dependent mods as I know of users that are doing exactly that. If you encounter any bugs or otherwise information, please let me know.

Thatmo is still using very old KSP 1.0 configs at this time as I never got around to adjusting it for 1.1's lighting and therefore looks really bright. No idea to be honest, sorry. CKAN integration is not an option at this time as I do not have a package that is ready for release yet. -------------- Sorry guys, I've been away for pretty much like 2 months without dabbling in KSP at all. Taking a breather, I'll be back and swinging into things when 1.2 drops and the modding community starts knuckling down getting this mod's dependencies up and running.

Sorry I haven't been around for a long time, taken a hiatus away from KSP somewhat. I'll be back when 1.2 drops and all the modding community gets back on track with the new patch.

@Nhawks17 should add you as a contributor to the SVE Git repo and let you run wild with it. At this stage, I am unsure as to why anyone would use anything other than a Git for their primary source for hosting.

Try adding a PQS deactivate distance into the configs for the gas giants, either through the GUI or by the following code: PQS_MANAGER { OBJECT { body = *body name* deactivateDistance = 175000 } }

It sounds like you were installing the EVE Config files without the actual plugin... ergo, no clouds will appear at all. Then you say you installed the full EVE mod and both cloud sets appeared. Well, of course they would, you've just installed the EVE plugin, the bundled EVE Configs and also SVE. It seems all would have been fine and worked correctly if you had installed as is instructed by installing just the EVE plugin and not the EVE cloud config files. At least, that's how it all comes across to me from what you've been writing.

Could albedo intensity possibly be controlled by a slider or an input value 0-1 etc. for the planet shine feature? I appreciate that is probably would be this bright and intense in the KSP system as the bodies are so close to each other but it comes off a little strong. If we could adjust it on the fly by a scalar the end user could decide on the effect's intensity.

It was a bit of a tasteless joke, don't worry.

Those panels in 1.9.3 were positioned 90 degrees off rotation in the model so I presume you've updated to 1.9.4 and the model has updated to be positioned correctly. The panels on new craft you launch should be fine.

Not that I am aware of, the ports just would not magnetize and pull or dock even if you bumped slowly straight at the ports. Gonna go test a few things. EDIT: Seems all the other ports are fine except for dockingport2 and dockingport3; being the regular, Clamp-o-tron Docking Port and the Clamp-o-tron Jnr. Does this tie into what others are experiencing?

Sorted.

Running the new dev build I am currently around Sarnus at a stable 130-150fps. When I waggle and spin the camera around it drops to around 85-90 and hit a low of 65. Quite a considerable gain for me.

Ah, I read that people were having issues with the bumpers but didn't realise it was known that they are not functioning. Do you happen to know the last version that they were working?

Not yet. However, after thinking about it, the way it is acting is how it should be so in that case the EVE clouds are going to have to be removed from the that cube map. Alpha map textures are not suited to being coloured in any way due to the way the sun is acting as a source of white light to it saturates the texture on all RGB channels in the colour parameter. So in any case, I give you this: https://www.dropbox.com/s/8b4itosy9zml2jk/StockVisualEnhancements.zip?dl=0 The clouds are on the following textures/channels: MainTex: StockVisualEnhancements/EVE/Atmosphere/Textures/cloud - Type: AlphaCubeMap, ALPHAMAP_R - Original Texture: kerbin1 MainTex: StockVisualEnhancements/EVE/Atmosphere/Textures/cloud - Type: AlphaCubeMap, ALPHAMAP_G - Original Texture: kerbin2 MainTex: StockVisualEnhancements/EVE/Atmosphere/Textures/cloud - Type: AlphaCubeMap, ALPHAMAP_B - Original Texture: low MainTex: StockVisualEnhancements/EVE/Atmosphere/Textures/eve - Type: CubeMap - Original Texture: EveClouds By separating the Eve Clouds texture to its own cube map and running it in a Greyscale opaque texture in the RGBA format, you bypass the previous issue and still retain the non-pinching of the texture at the poles and a low file size. In total I think the UR sized textures come in at a total of 47MB or so. EDIT: Try it out, see if it makes a difference positively/negatively compared to how you're running it at the moment and let me know. If you have any ideas or critiques I may be able to fiddle with them somewhat. Also, if you seriously want to run with this, do you have the original raw textures used for these images as saving as a .dds causes pretty bad compression so for a release batch it would be worth using the originals as the source?

Is anyone else having issues with the docking ports in 1.9.4? I'm finding that it feels like the ModuleDockingNode transforms may not exist on the models and therefore the ports refuse to dock or attract to each other?

Ah I see, I don't suppose it takes a lot of inspiration from Halley's Comet, does it?

Well if you compare it to other bodies of small size and use the 5km radius of Sorlon as a ratio you get the following: Gilly 13km (Stock): 0.049m/s^2 ---> Sorlon 5km: 0.0188m/s^2 Hale 6km (OPM): 0.023m/s^2 ---> Sorlon 5km: 0.0192m/s^2 So around 0.019m/s^2 would be reflective on a median value between them. Then its just a case of considering Sorlon's make-up and adjusting to suit.

I would suggest something along the lines of an ASL Gravity coefficient of 0.0192m/s^2, roughly around 1% of what it currently has. @Proot, any thoughts on this?

Well not for me, I must be doing something magical:

You just right click on the link to the files and chose 'Save link as...".

You can view the Pruners directory from the source repo and download all the (most likely for yourself) .bat files for each category to a folder in the root KSP directory: https://github.com/VenVen/Stock-Revamp/tree/master/Pruners Download them all and then just run them. You can verify they have worked by going into one of the asset part folders in the GameData\Squad directory and it will have renamed the .mu and .dds files for those parts as expected.

I presume its a simulated shadow texture on an EVE layer that is set to rotate around the planet once every solar period so it aligns through the sun. Getting the layer rotational speed correct must have been/must be an absolute pain in the backside.

So it would be best practice in this case to use Kopernicus to cull all stock scatter and then re-add it through Kopernicus itself to ensure colliders are enabled?

Well KSP uses libNoise to generate its terrain so the Kopernicus hook-ins are dervived from it. Look at the example of the image map libNoise uses in its tutorial/example: http://libnoise.sourceforge.net/examples/complexplanet/images/planet.jpg Familiar much?

For parameter value definitions, you can grab them straight from the libNoise glossary: http://libnoise.sourceforge.net/glossary/index.html