Poodmund

I'm not sure if Proot changed the default configs but as the new Scatterer config syntax has changed, yes, as you pointed out the new default Scatterer configs would have to be used or the KSPRC ones ported over.

Shady area there, man. It's listed under a CC-BY-NC-ND license and technically even if you're just updating the dependencies in the bundle and not touching any of Proot's own material it would seem to me it's still going against the license. A better approach would just be to create a very detailed step by step tutorial on how to get it working on 1.2.2 with all the links to current downloads etc.

If a high signal strength is your aim for Eeloo comma then yes, a high powered relay satellite in Kerbin's orbit (operating at near 100% signal strength) would be preferable as a connection link due to its power being probably much higher than the DSN3's power. I just used the DSN3 as the example as that's what you had used as a reference in your post. However, there are issues with this and how KSP handles links. I'm fairly certain that if you put the relay in Kerbin's orbit, the satellite at Eeloo would still disregard it and want to talk directly with the DSN. This is due to the pathing limitations within CommNet and how it acts. It seems to prefer to always talk directly with a DSN station if possible, even at a lower signal strength, to avoid infinite looping situations. Where Science transmission is concerned multiple hops are not an issue. The final Science gain is the product of the signal strength at each hop, i.e. a link to a low Eeloo relay from Eeloo's surface is 50% and then the link back to the DSN is 50%. Any Science transmitted will yield a net 25% return. To get around these issues with CommNet's pathing and potentially losing Science yield, I would recommend using DMagic's Science Relay mod where you can force to move your Science between specified crafts to route it back to the DSN to avoid any signal loss. I hope this helps explain things a bit better.

Not quite, even with the DSN3 and a craft with 11 RA-100 Relay Antennas, you'll still only get 75% Signal Strength at Eeloo's (rough) max distance of 127Gm. i.e. DSN3 Power = 250,000,000,000 Craft Power = 100,000,000,000 * 11^(0.75) = 604,010,535,454 (This is a very simple calculation as the craft is using all the same antennas) Max Range of Comm Link = SQRT ( 250E+09 * 604E+09 ) = 388,590,573,565m Ratio of distance we want to communicate from over the maximum link distance possible = 1 - ( 127 / 388.6 ) = 0.67 So from this we can say that the vessel at 127Gm from Kerbin is around 67% of the way between the DSN Station on Kerbin and the max communicable distance. As KSP calculates in-game signal strength by taking this ratio and applying it through a Bezier function, being y = ( 3 - 2 * x ) * x^2, we get the following in-game Signal Strength. y = ( 3 - ( 2 * 0.67 ) ) * ( 0.67 ^ 2 ) y = 0.745 or 75% As you can see it takes a bit of work.

Please note that I have made quite an extensive write up on this on the CommNet Wiki page, you may want to check it out for further reference: http://wiki.kerbalspaceprogram.com/wiki/CommNet

Off the top of my head the mapViewScale for me seemed to be dynamically scaled/calculated from the Proland Configuration tool...? Is that a possibility?

Seems rather large for a float value.

Looks as though you have both EVE and Scatterer's eclipses enabled. Turn one of them off.

I was using %Scatterer_atmosphere and so on for the others, % being Edit existing or Create if none found.

Thank you for the heads up. I think I've fixed all the erroneous formulas... I am not sure how they get changed as I've locked the cells but somehow it may be to do with users copy and pasting parts. I have no idea. Anyway, thank you for the submission. I will get around to adding it at some point.

I am using the same method as cy4n to implement Scatter in my own mod directory for the OPM bodies but I am having issues where the default Scatterer files/configs need to be present for my own configs to work and also the config path for the modded bodies all default to the default Scatterer, Duna config path in the GUI. Let me know how you get on with it if you may. My ultimate test is to create a Scatterer config that works outside of the main Scatterer directory with only the Scatterer .dll present. It does not seem to function fully in this way at the moment but that would be the sure fire way to test whether MM hook ins are working fully and as expected.

I can't vote either, I reckon it must be an IP Address thing... ? Anyway, I'd vote for #2.

Creating Procedural Planet Textures (Heightmap & Colour) using Adobe After Effects Abstract To create an Adobe After Effects template that will allow for the generation of Planet/Moon Heightmap and Colour Maps for use with KSP by utilizing fractal noise layering to allow for ease of use by those that may not understand noise generation or subsequently, PQSMods/libnoise functions. The Adobe After Effects project can be download and used from here: https://www.dropbox.com/s/zss8ydp80zm6h7b/Planet Textures.aep?dl=0 ----- I recently rediscovered the power and effectiveness of After Effect's Fractal Noise libraries whilst working on unrelated projects and considered that it would be a powerful tool when used to create base textures for planetoids in KSP; if utilised correctly. Due to the way After Effects generates the noise, most noise created would be generated outside of the -180 to 180 degrees phase and therefore would not be seamless in the workspace and also the noise is created in a rectangular image space and therefore there would be significant 'pinching' distortion at the poles. To rectify this, the noise image space can be distorted using polar deformation to remove this issue and finally some manual seam blending can be introduced using a small mask to cover any inconsistencies that blends in with its surrounding environment. Finally, the resulting greyscale heightmap can be colourized depending on the lightness using a custom gradient scale to create a coloured ScaledSpace texture that varies with colour proportional to altitude. These textures can be rendered out of After Effects (at 8192x4096 in the attached project) for further use within KSP or for additional image manipulation work. The greyscale heightmap can be passed through a normal map generator to give you the bump map to be used in-game (remember that KSP uses inverted Red to the Alpha channel and the Green channel duplicated to RGB). Anyway, I have done some quick and dirty previews as to what can be achieved with not a terrible amount of effort, as you can see, bodies with complex and noisy terrain can be generated alongside those with mostly flat, rounded slopes: The above planetoids have all been generated using textures rendered straight from After Effects with the normal maps used being from the http://cpetry.github.io/NormalMap-Online/ tool by utilizing the greyscale heightmap. Above is a preview of one of the example bodies shown from Front, Left, Back, Right, Top & Bottom respectively to show the total lack of polar 'pinching'. Mini-guide Below I will list the respective stages of the process within After Effects to allow for the easy use of the attached project above. Panel 1: Noise Layers In this panel, you are required to generate the main features of the terrain by using multiple layers of fractal noise to build up a greyscale, rectangular base for your heightmap. As you can see, in the example above I have layered 6 noise layers to create the shown effect. The parameters listed against the Fractal Noise effect can be changed to alter the generated noise to your liking with a dynamic preview being shown in the composition work space. Ensure to layer blend your multiple noise layers to obtain the result you desire. Panel 2: Polar Distortion This panel requires no input by the user and simply takes the generated image from Panel 1 and applies the polar distortion required to create an even and consistent terrain distribution at the poles. Panel 3: Seam Blend for Heightmap The source image from Panel 2 is shifted horizontally by half a phase to show the seam error in the center of the image space. The mask in this composition can be resized, the feather adjusted and the opacity altered etc. to try and completely remove the seam whilst maintaining a good transition in the terrain on either side. This process can be seen below: This finalizes the greyscale heightmap for your body. Panel 4: Colourization The Colorama effect is applied to the source image from Panel 3 that allows you to create a gradient map that is directly proportional to the brightness of the texture. Many effects can be created here in the way that LUTs are used to colour terrain maps, realistically or not and even to reflect habitable Earth-like worlds. In the example below a simple rocky style gradient has been applied. Panel 5: Spherical Preview In this panel, you can rotate the colour map on the X, Y and Z axis (Y axis being the most useful) to give a real time preview of the body as a sphere. ---------- Once you are happy with your terrain maps, simply add Panel 3 and 4's composition frame to the render queue and generate your heightmap and colour map textures respectively. Ultimately, a Kopernicus config will be required to be written to use your textures to create the body within KSP. ---------- Disclaimer: I appreciate the fact this may not be a desirable way to generate terrain for use within KSP as basing your terrain of a heightmap texture can cause some rough, pixel'y terrain at the pixel boundaries... especially on larger bodies. Nonetheless, PQSMods still remain a confusing matter to many people and this method may be "good enough" for some to achieve the results they require. I post this up as a fleshed out proof of concept and nothing more.

You can always take the cube map, convert it to equirectangular and then composite existing gas giant features/bands/etc. over the top to create hybrid textures... or is that what you have done?

Well if it makes any difference, that particular demo used an Advection Procedure to simulate the fluid flow at the boundary layers between the bands. ... and also of note, seeing as its Unity base, I came across this a while back that was interesting nonetheless: http://vfxmike.blogspot.co.uk/ @blackrack, I presume that blitting like this would impose quite a large memory footprint texture wise and also be CPU heavy?

In that particular demo by Stephen Cameron, the warped noise effect only gets more extreme as the distortion is run and as said by himself, there is always a sweet spot in the generation as to where the output looks "best". However (and I did send this to blackrack and Waz a while back) take a look at this: That's the level I don't think we'll ever reach but we can only hope... right?

I was never really a fan of that as the noise movement looked very much like standing waves rather than transverse if you get what I mean. It didn't feel as though the distortion was travelling around the body as much as it felt like it was just warbling in place.

And to this effect, Scatterer already does this by using its postProcessAlpha/Depth/Exposure nodes at differing altitudes. We already have this in the game with Scatterer.

Sorry, unfortunately I did not release the textures in that .gif. However, there are TONNES of hurricane images on the net, especially on NASA's image galleries of which all are GPL. Yes, as the texture is just 1 face of a cube map located Top or Bottom of the cube that is rotating around the polar axis, the texture will always persist in that cloud layer. It's just the same as any other cloud layer in that respect. For practical use, it would be better to reduce the size of the storms considerably to not have an overbearing effect. The same technique can be used very effectively for auroras and I also used it to recreate Saturn's hex-storm on Sarnus for OPM-VO.

Loving the ring shaders but as far as more visual work goes, I would prefer for the Module Manager config compatibility to be properly nailed down before moving forward with additional features. Currently, if you remove all the Scatterer stock configs and textures and try to introduce a config for a body with the config files located outside of the Scatterer directory, it all falls down as for some reason it tries to default the config location path to the Duna folder in the Scatterer directory... which seems very weird. To reproduce I install Scatterer on a vanilla build, delete the GameData/scatterer/config directory and then create a planetsList style config and an atmo config (with textures) for any body in GameData/*Test* directory. I know it might sound like I'm beating a dead horse here but its a real issue when trying to promote positive compatibility between visual packs without encroaching on Scatterer's main directory; but thats just me and I appreciate that it doesn't add a shiny new feature so its not a popular request.

You're my hero!

Does this help at all? https://kerbalspaceprogram.com/api/interface_comm_net_1_1_i_relay_enabler.html If not could the part just have a combinability exponent of 0, be set as a relay and have the power of that relay antenna set to a dynamic value based on the highest, combined vessel antenna power?

Haha, yeah chuck your Output log and KSP log up for me to check with anything else you may think is handy and I'll take a look. I can't have your Space Programme telescope images coming back with errors due to faulty CCD sensors.

I have some pretty updates planned for some bodies in future patches to allow you to scan your biomes with KerbNet in super-fashion style. Get hyped!

Yeah I was trying to work with the lasted dev build of Scatterer and it just wasn't playing well with EVE at all. Waz and Blackrack are aware of the issues, we will just have to wait patiently for further development.