The White Guardian

You definitely are!

0_0 x 105 My goodness, this pack is a gem! @AndrewDrawsPrettyPictures, I tip my hat to you.

If Kopernicus does not touch the stock planets, then yes it should be easier for the computer to handle. Keep the following in mind however - it will not be a big change. KSP was made very, very cleverly - you have to get close to a planet for it to start rendering the terrain. From far away they are nothing but textured spheres. If you want your game to run faster, try decreasing the texture resolution. It is by far the most consuming.

Didn't know that 0_0 Note to self: make a pack that does just that, for performance's sake

Kopernicus loads and unloads textures on the go, so it wouldn't really matter performance-wise. EDIT: what matters is the amount of planets on-screen, and how big their textures are.

Oooooh! The accretion disk is fully functional thanks to my own update of INSTANTIATOR (making some final adjustments before public release) Evolution itself has some last fixes necessary before the first public release.

Galaxy??

Thanks!

Evolution is starting to rise again, this time in 1.3! More eyecandy Time for hype, people.

Good call, since Time.deltaTime ignores time warp it should be multiplied by the current time warp as well

@Thomas P. would it be possible to make a small change to HazardousOcean? I propose the following alteration: Current: foreach (Part part in vessel.Parts) part.temperature += heatingRate; Proposal: foreach (Part part in vessel.Parts) part.temperature += heatingRate * Time.deltaTime; For those that don't follow: Currently HazardousOcean adds the 'heatingRate' to the temperature of a part one per frame, which isn't that constant. (Update{} method -> executed once per frame) Let's imagine a HazardousOcean-planet with a heatingRate of 2K at 5000m. On a potato computer, with 10 FPS, parts would heat with: 10 * 2 = 20 Kelvin per second, but on beast computers, smashing KSP with 120 FPS, parts would heat with: 120 * 2 = 240 Kelvin per second. Potato: 20 Kelvin per second Beast: 240 Kelvin per second As you can see the difference is massive. Multiplying the heatingRate by 'Time.deltaTime' (the time in seconds between the current frame and the last) would scale this down to be universal across computers of all strengths. This would also make the HazardousOcean curve easier to use - instead of the somewhat confusing 'temperature added per frame' for the Y of the floatCurve, users would get 'temperature added per second', which would work a lot nicer.

I know, it's pretty massive...

Not per second, per frame.

Update on EVOLUTION: I'm re-organizing some stuff under the hood for faster load times, and to allow potato-grade computers to run the mod. I'm also going to have to do some cleaning (+6 GB of RAM required to start with EVOLUTION is just not acceptable)

You quoted me explaining a custom shader, don't use that info to edit Unity's built-in shaders - the names of the shader properties differ. For the sake of other people subscribed to this thread, I'll put the following in a spoiler.

I'm getting close to making @Artyomka15's idea of easily editing all shader settings a reality. This new config node type allows the user to set up several 'passes', each of these passes editing one shader property. Thus, INSTANTIATOR code may get rather long, but the ability to customize everything will probably be worth it.

Those have no alpha channel (Unity sets black to transparency) so I'd guess DXT1. If that doesn't work, use DXT5.

Too high quality. Evolution seems like KSP Old Spice - too powerful Thus it'll be released in a format similar to @Galileo's amazing SVE mod - you download two packages. Package 1: the core mod (all of the configs, and textures that can't be cropped such as Scatterer .half textures) Package 2: all of the texture works, served in a variety of resolutions: Insane resolution: 8K textures Epic resolution: 4K textures PC-friendly resolution: 2K textures Though I do think part of why it currently costs so much RAM is because of some nasty scatterer-related NullReferenceExceptions that I'm still eliminating. I actually feel like changing the main star name back to Sun and leave it mentioned as Audentia in things such as science reports, so that other planet mods work right off the bat, otherwise Scatterer will break.

I believe I was in the process of adding a second star named Cyroa...

What exactly are you seeing when you try exporting as DDS? I get a pop-up window that allows me to set the export criteria. What you're looking for: - Color maps for oceanic planets (Laythe, Kerbin, Eve, etc): DXT5 - Color maps for non-oceanic planets (Tylo, Moho, Dres, etc): DXT1 This is because, for oceanic planets, the transparency of the 'land pixels' determines the shininess. The 'ocean pixels' should not have transparency. - Normal maps (blue format): DXT5_nm - Normal maps (Kittopia export): DXT5 - Height maps: no compression, but set the format to L8 Note: You find DXT5, DXT5_nm and DXT1 under the 'Compression' drop-down menu, and L8 is found under the 'Format' drop-down menu. Also keep the following in mind: Unity flips DDS textures vertically on load. I'm not sure why, but it does. For example, if one were to load two identical planets, using the same maps, but with one planet loading the maps in DDS and the other loading the maps in PNG, the result would be two identical planets, but with the maps flipped vertically. Therefore, if you want to convert from PNG to DDS, make sure you flip the image vertically before exporting. GIMP can do this in the 'Image' drop-down menu, from there go to 'Transform', and select 'Flip vertically', or whatever it was called.

I'll think about it, and see what I can do.

That seems like a problem with the ocean programming of Scatterer. Could you try opening the debug console, see if there are any exceptions being thrown over and over again?

Update: the shader is nearing completion, here are the details: Properties: Texture: main texture Texture: normal map Color: main color Texture: detail texture Float: detail intensity Float: boost Texture: misc texture Color: emission color So, what do they do? Main texture: the main texture for the object Normal map: the main normal map for the object. The normal map, if added, creates 'light anomalies' to simulate geometry. Ergo: you make it seem like there are dents for example in an object without those dents actually being there Main color: the main texture is multiplied by this color. This allows you to recolor the texture on the go. Detail texture: a second texture drawn over the main texture. Use scale and offset to add detail to objects, so that the immersion isn't broken when the camera is close to the object Detail intensity: this value controls how much the detail is applied, use this to reduce detail effect if necessary. Should be between 0 and 1. Boost: the r, g, and b values of the main texture are multiplied by this value. Boost can be used to boost the colors should the texture be too dark. Misc texture: perhaps the most confusing thing here. This texture is broken down into channels: red, green and blue. The intensity of red in each pixel controls the 'metallic' value The intensity of green in each pixel controls the shininess The blue pixels are the most interesting: they control the intensity of the emission. Ergo the more blue a pixel is, the more this part of the object ignores shadows. So to create an unlit texture, enter a fully blue texture. Emmission color: this color is applied to shadow-ignoring parts, good for adding colored glow effects How to set up a misc texture? - Create a grayscale texture for each of the channels - the lightness of the pixel controls how much of the effect of that channel is applied. - Next, in GIMP, you can use the Curves tool to remove all channels but the one you want. I am currently creating a new Config Node for INSTANTIATOR that uses this shader for maximum control.

Hmm... I suppose KSP's solar panels work through a raycast-like system: KSP attempts to draw a line between the craft and the nearest star; Should this line be uninterrupted, electricity is generated, otherwise the program returns the object causing the interruption. This can be a part, a planet, etc. Unless I learn how exactly KSP's system for detecting interruptions works and can write a workaround, I doubt I can fix it the 'traditional' way, but worry not, I have a solution. The current way INSTANTIATOR adds objects is through a cube, which is then stretched and flattened immensely. The result is a narrow strip through which light cannot pass. @Artyomka15 probably devised this system to avoid something called 'back face culling'. You see, every rendered object in KSP has a textured side, the front face, and a transparent side, the back face. Default Unity shaders set this back face to transparency. Thus, a cube-based INSTANTIATOR object appears textured on both sides because the outside of the cube is drawn. The method I propose requires a custom shader, one I am currently crafting for INSTANTIATOR. This shader blocks culling of any kind, ergo, both sides of a mesh' normals are drawn. The idea I have can be executed currently but requires two objects, one with inverted normals, but once the shader goes live, modders should be able to use a 'plane' as a base object for an INSTANTIATOR instance. A plane is nothing but a flat square - it is entirely 2D. It has only one face, counts 2 tris and 4 vertices. Because this leaves a plane infinitely small, light blocking of any kind should be minimal. (think of no to less than a meter of light block). Other features I am trying to add to this shader: - Detail textures: assign a second texture to provide even more detail to the ring, even from up-close - Emission textures: choose which areas are light-affected and which are not - Normal maps: add 'fake depth' if you so desire And future INSTANTIATOR features (gonna take some effort to make...): - Import custom meshes - Add particles to an object - Patch through ModuleManager instead of editing Objects.cfg directly MFI exceptions when adding around other stars? That's something I am not aware of, let's see if I can find the cause.

Hmm... let's see if I can add this before this weekend. I expect it to be a simple Vector3 sum, here's hoping I'm not very wrong...