Borisbee

For starters, you're applying the color map of the old Erin to the new Erin. Erin was never supposed to have a color map applied to it, it uses stock Laythe landclass for it's texture. Just apply the heightmap with deformity of 8000 and a -2000 offset (stock laythe heightmap settings) and then export the new scaledmesh. It should look pretty much like the original PF erin at that point.

Sounds like I need to make a modulemanager patch for DRE. The temperatureMultiplier needs to be lowered in order for it to not act like it's hitting a brick wall. If you want a quick fix, edit the tempMultiplier yourself from 5 to 2.5.

This isn't really a bug, but more of the PQS not being set correctly. The fading you see is the transition from scaledspace to local. Your color map is not being applied to the planet so that's why you see it fade away when you get closer. Look to see if you have a color mod on the planet that's interferring. Click the save button, and paste your planet config here.

I think you may just not understand how the PQS mods work. I was able to get Erin looking as it should.

Even better idea, fix the PF planets so they actually match up. Erin for example is completely wrong. I may end up releasing my own version of those planets.

So I went ahead and made a quick fix for Kittopiatech to add a recursive search to the SaveLoad folder after getting tired of the folder being filled with tons of planets from all the mods. Now you can keep your mods planet configs seprated in their own folders. I submitted the pull request if you want to take a look at the changes. It's literally like 4 lines of code.

Yea, the other thing it could use is a little more variation in height. Overall it seemed relatively flat. Btw if you want to know how to get the atmosphere to show up in map mode, add a gradient to kopernicus config, and make sure ModScaledAtmoShader = False in Ixium.cfg If you're going for a snow/ice world, I'd try light blues and maybe some greys. Going pure white is likely to come off really bright.

So I played around with Ixium a little. When I went to it I noticed the terrain didn't really match up with the scaledmesh, and the oceans were really just small lakes. I also noticed the map view uses a texture to supply ocean color which has the side effect of making it look like terrain instead of ocean, and doesn't match up with the rest of stock bodies. I took the liberty of trying to tweak it some and here's my results. Notice the terrain now matches up pretty well, and the oceans are full on oceans. I also added the atmosphere effect to map view so it actually looks like there's an atmosphere over the planet. If you want my new height map let me know. I basically took the heightmap and selected all the ocean and changed it to black so that the terrain will actually drop down a substantial bit. Then it was just a matter of tweaking the offset a bit, I think -1680 is what I ended up using. I like what you're going for though. I also really like Stenci. I saw the pictures, but once I got ingame and really looked at it I thought it was a pretty cool idea for a gas giant.

I don't have much experience with this, but I'd start by using laythe or eve as a template and going from there. Edit: After playing around a little I can add a little more information. Use laythe as a template for example, and then it's just a matter of using a heightmap with some variance in altitudes. Set the areas you want to be ocean in the heightmap to black so it's clear it should be depressed, and then in the PQS mod set a negative offset until you're happy with the results.

Going to repeat this. Turn your normal map opacity down to 50% in photoshop or whatever and you will fix any lighting bugs. - - - Updated - - - Agreed

I haven't tried it either yet, but I feel like you probably hit the nail on the head here. It likely means Ovok will need a slightly larger SOI so that you can get into a stable orbit and still have wiggle room without smashing into the ground. Actually kind of cool if you think about it because it can act as another challenge of trying to get and intercept and land without crashing. Or I guess you could just come in on a heavy inclination.

Absolutely. Please keep taking your time and come up with original and creative ideas. I know I and many others here are glad for it. Too many people think exporting a spaceengine texture and calling it a day is proper planet creation. Quality over quantity always.

Those planets are looking pretty good. I can confirm the problem you're having with Duna as a template. I wanted to create a mars using Duna as a template, but the ground just would not come out correctly for whatever reason. Kind of frustrating. - - - Updated - - - Downloading OPM is all you need. OPM contains the required .dlls and just overwrite whatever you have.

Hrm, odd. I'll test later to see if I have same issue but I haven't had that happen to me I don't think. You're running the latest .dlls yea?

I asked Teknoman117 about this just the other night. Here is his response. http://forum.kerbalspaceprogram.com/threads/88168-Early-development-0-24-Kopernicus-Planetary-System-Modifier?p=1729608&viewfull=1#post1729608

The easiest way to do it is get on the launch pad and edit Kerbin. Open the atmosphere editor and open the colorwave box thing and play with the sliders until you get the right color you want, then copy the numbers. The lightColor uses a wave and doesn't take a straight RGB value, that's what confused me at first as well.

If it should be pink, then your color is setup wrong because the color was green on the ground also.

Why are you distributing OPM textures and .bin files along with your own stuff?

Oh sorry, I got confused Yea, the texture = is for the color map, so keep that. I'm not sure why you're having issues, seemed to work fine for me.

Fairly certain the issue is "texture = Kopernicus/Textures/Porp/Porp_map" Not only is that unecessary since you're supplying a Gradient, but you used it wrong. It should be rimColorRamp= You only need one or the other. You can use a texture to supply gradient, or supply it manually with the Gradient {} That's kerbin with your supplied config. - - - Updated - - - Because as far as I can see, stars are not supported right now. Just focus on planets for the time being. I don't even want to add stars unless they are done properly anyway. IE: solar panels work from both light sources, and planets receive light from multiple sources. There is so much more work left to be done I'd rather have working PQS system in before we start adding superfluous stuff like this.

You're gonna need larger numbers for deformity. The larger the deformity, the larger the difference in the shape you'll see. Just use trial and error. type in numbers and hit rebuild over and over until you get something that looks good. There is a lot of trial and error in planet making to find what looks right. It's more of an art than science right now. Also you're putting that in the wrong config. Don't put it in kopernicus config, you want it put it in the kittopia config inside SaveLoad folder - - - Updated - - - My picture is using a PQS mod like Tellion said, but as you've also found out using gradient heightmaps can also result in egg shaped planets. This is harder to get right though as the texture needs to be seamless or you get ugly borders where they meet.

I think that's set by lightColor. Did you set that?

Gravitasi, I was wondering if you could explain the way you generate scaledspace mesh. I'm wondering because if you add a PQSMod_VertexHeightOblate mod and try to generate the scaled mesh, it comes out as a sphere even though it should be more eggshaped. Is this a limitation of the current mesh generation? I took a look at the source code and unfortunately I'm not very knowledgeable in the way KSP does it's planets so I couldn't figure out where the issue was. The only thing I can guess is because it's using Jool as a sort of template that it defaults to a sphere and ignores modifiers that change that? Although that doesn't make sense either since it can account for heightmaps.

What do you mean support for OPM? As in make them orbit the gas giants instead?

Ok thanks that explains some things better. The way things work now is the gradient is what you see from scaledspace, so it's what applies the thin layer over the planet so it looks like there's atmosphere there, and it works rather well as far as I can tell. The lightColor is what you see from the ground, and determines the color of the sky and how fast it fades. I started getting curious because it seemed tough to get a very light color to have a slow fade high in the sky, but I guess you kind of explained why that would happen. It needs to be a brighter color in order to go higher. You're right in that tweaking the values too much can cause very wonky things to happen, like the cutoff being very abrupt instead of gradually fading. In the end, it would be pretty awesome to be able to specify a gradient much like the scaledspace, where you can set exactly the color and how high/low you want it to fade but I think that can wait until way down the road. Other much more important things to be done first like the PQS system. Words can't describe how happy I'll be when we can start doing PQS editing without having to deal with kittopiatech, letting us use all the PQS mods and opening up much more creativity in planet creation. At one point I was going to hardcode the planet I was toying around with, but I wasn't quite able to get my custom hardcoded planet and the config planets to both load. It was either one or the other.