narhiril

V1.1 is up on Spacedock and marked for update on CKAN (this may take a little while to go live). I've still got a few reference images for new skins and I also am planning to look into using Firespitter to consolidate parts into a single parachute with skins chosen through tweakables. I'm not completely thrilled with having a dependency for a mod as small and simple as this, but if I continue to add more chutes, the parts clutter is set to get really out of hand. I guess anyone running more than the smallest handful of mods is going to have Firespitter anyway.

@The White Guardian It seems you're getting pretty good with EVE. Kallahan looks really interesting - I'm quite fond of desert worlds.

I actually hadn't considered that. I'd be happy to look into doing that, though I'd like to get the essentially finished Quest parachute released first. My schedule is a bit busy tonight and tomorrow but here's a preview of the Quest chute. Chutes will also be radially attachable in the next release - that they weren't already was an oversight on my part.

I look forward to seeing this. I guess I have two questions about terrain scatter. since that tends to be what I use LandControl for most often. 1) Do you have a list of valid scatter names? 2) Is there a way to add custom scatter models? Guessing the answer here is "no," but figured I'd ask.

Sorry to necro this post from October, but I would really like to know the solution to this and I couldn't find one. Right now, the only way I can get my rings and moons to consistently be coplanar is to set inclination to 0 for both of them, and I really would like not having to do that if at all possible. Basically, to reiterate the problem, I can set my ring system to an angle and then manipulate the orbits of my moons to match up with its plane, but upon re-loading the game, sometimes it gets screwed up, seemingly randomly. It's as if the longitude of ascending node for the ring system is not fixed and changes on a whim for reasons I can't figure out, and there's no way (that I know of, anyway) to specify it within the config. Locking rotation just makes the ring plane sort of wobble around the planet unrealistically.

Just another quick update - I can see no reason why this shouldn't work in 1.2.2. I haven't given it a bump on CKAN yet, but you should be all clear to use it. I've had an abnormally taxing holiday season and what little free time I've had has been going towards a planet pack that I'm working on. I am, however, finally getting around to finishing a Quest parachute texture. Expect to see that coming in a day or two.

Thank you, I was wondering what was going on. I had just been putting them there because that's where all of my textures had been up until this point. I'm pretty much flying by the seat of my pants with this.

I took your advice and rebuilt the config from scratch in the EVE interface. Strangely, the EVE UI still could not parse my file path. On a whim, I decided to move my cloud texture to a different sub-folder and try that. For some reason, that fixed the issue and EVE could find it all of a sudden. Things are mostly working now - just have to tweak some settings to get it cleaned up. Thanks a bunch!

Thank you for replying... unfortunately, I'm still unable to get it working. I've screenshotted the error alongside the file path to the image. It would make sense if I'd somehow screwed up the file path, but I've checked it probably going on a dozen times now. Error in the output_log is the same: EVEManager: Issue loading CloudsManager! Error: UnityEngine.UnityException: Unable to apply node! ---> UnityEngine.UnityException: Unable to parse "settings" in "OBJECT"! ---> UnityEngine.UnityException: Unable to parse "_MainTex" in "settings"! ...Followed by the same stack trace as before.

I think this is the right place to ask something like this... I'm doing some work on a Kopernicus planet pack and I'm trying to get EVE clouds to work on one of the new planets. I found another planet pack that does EVE clouds (Extrasolar) and tried to reverse-engineer the configs from that. My problem is that EVE absolutely will not under any circumstance load my texture, and I have absolutely no idea why. The config file in question (RogueWorld_EVE.cfg): EVE_CLOUDS { OBJECT { name = Shedu_clouds1 body = Shedu altitude = 380000 speed = 0,20,0 detailSpeed = 0,6,0 offset = 0,0,0 settings { _MainTex = RogueWorld/KerbolSystem/KopernicusConfigs/Planets/PluginData/clouds/shedu1 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _DetailScale = 120 _DistFade = 1 _DistFadeVert = 4E-05 _Color = 225,5,17,255 _DetailDist = 2E-06 } layer2D { shadowMaterial { } macroCloudMaterial { _FalloffPow = 2 _FalloffScale = 3 _DetailDist = 2E-06 _MinLight = 0.5 _RimDist = 0.0001 _RimDistSub = 1.01 _InvFade = 0.008 } } layerVolume { size = 4000,2 maxTranslation = 0,100,0 area = 24000,4 particleMaterial { _TopTex = BoulderCo/Atmosphere/Textures/particle/rgb _LeftTex = BoulderCo/Atmosphere/Textures/particle/rgb _FrontTex = BoulderCo/Atmosphere/Textures/particle/rgb _LightScatter = 0.55 _MinLight = 0.5 _InvFade = 0.008 } } } } The relevant error in the output_log: [EVE CloudsManager]: Unable to parse config node: OBJECT { offset = 0,0,0 detailSpeed = 0,6,0 speed = 0,20,0 altitude = 380000 body = Shedu name = Shedu_clouds1 settings { _DetailDist = 2E-06 _Color = 225,5,17,255 _DistFadeVert = 4E-05 _DistFade = 1 _DetailScale = 120 _DetailTex = BoulderCo/Atmosphere/Textures/detail1 _MainTex = RogueWorld/KerbolSystem/KopernicusConfigs/Planets/PluginData/clouds/shedu1 } layer2D { shadowMaterial { } macroCloudMaterial { _InvFade = 0.008 _RimDistSub = 1.01 _RimDist = 0.0001 _MinLight = 0.5 _DetailDist = 2E-06 _FalloffScale = 3 _FalloffPow = 2 } } layerVolume { area = 24000,4 maxTranslation = 0,100,0 size = 4000,2 particleMaterial { _InvFade = 0.008 _MinLight = 0.5 _LightScatter = 0.55 _FrontTex = BoulderCo/Atmosphere/Textures/particle/rgb _LeftTex = BoulderCo/Atmosphere/Textures/particle/rgb _TopTex = BoulderCo/Atmosphere/Textures/particle/rgb } } } (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) EVEManager: Issue loading CloudsManager! Error: UnityEngine.UnityException: Unable to apply node! ---> UnityEngine.UnityException: Unable to parse "settings" in "OBJECT"! ---> UnityEngine.UnityException: Unable to parse "_MainTex" in "settings"! at Utils.ConfigHelper.LoadObjectFromConfig (System.Object obj, .ConfigNode node) [0x00000] in <filename unknown>:0 at Utils.ConfigHelper.Parse (System.Reflection.FieldInfo field, System.Object& obj, System.String[] value, .ConfigNode node) [0x00000] in <filename unknown>:0 at Utils.ConfigHelper.LoadObjectFromConfig (System.Object obj, .ConfigNode node) [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at Utils.ConfigHelper.LoadObjectFromConfig (System.Object obj, .ConfigNode node) [0x00000] in <filename unknown>:0 at Atmosphere.CloudsObject.LoadConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at Atmosphere.CloudsManager.ApplyConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 It seems to be having trouble with my file path for the _MainTex field, but I don't know why. I've double and triple checked that this file path is valid - it points to a standard 2048x1024 png image texture. I have tried replacing it with a dds image with the same error, and the config file I've been using for reference uses the same syntax as I have (starting with gamedata subfolder, ending with texture image name without file extension). Frankly, I'm completely at a loss, and I was hoping someone here would be willing to point out the extremely obvious error that I'm sure I'm missing. Oh, and, in case it's relevant, this is on a fresh install of 1.2.2, with only the latest version of EVE, Kopernicus, KittopiaTech, and the work-in-progress planet pack.

I can at least answer your normal/height map question. Normal maps and height maps are rectangular images that contain information that the game can use for various purposes. Height maps are black and white maps that can be used to generate terrain (either as a replacement for or in combination with other PQS mods) using the VertexHeightMap mod. You can pull them from other sources (i.e. SpaceEngine), make them by hand, or generate them from other PQS mods using KittopiaTech. Here is an example of a height map - this one was made by hand: This is an older version of my height map for Shabriri (a moon in my work-in-progress planet mod). In this image, the darkest areas represent low altitude while the lighter regions represent higher altitudes - the closer to white, the higher the area is. You should be able to clearly pick out some big, low basins and the rather obvious lightly-sloping mountain formation. Here's how you use VertexHeightMap to generate terrain: Normal maps are a little different - the best way I can describe them is that they give the game lighting information to create the illusion of terrain detail in the scaled space - which is how your planet appears at a distance. Rather than trying to make one by hand, you should allow KittopiaTech to generate these for you once you're happy with your terrain by using ScaledSpace->Update Textures. These will be saved in GameData/KittopiaTech/Textures/YourPlanetName.

There's also a "PQSCity2." I have no idea how either of them work, but that one at least has a name string. https://kerbalspaceprogram.com/api/class_p_q_s_city2.html I know that most planet builders who have done easter eggs use Kerbal Konstructs for it, but I'd like to know how to do it the stockalike way - for things like SCANSat being able to pick them up. I haven't seen any examples of that and I want to know if it's even possible to do.

I'm glad I could help! Thanks for the hint about normal maps (something you posted ages ago in another thread), I never would have figured that out on my own. From now on I'm going to use Kittopia to generate my normals rather than building them from my height map. I'm so glad this fixed it, as it means I can continue to do my height/color maps by hand and get some good results (and then throw some voronoi craters over it afterwards for good measure). So here's what I'm considering my "final" result. Hand painted color map and height map with procedural craters added on top.

So... apologies for the double post, but I decided to investigate my hunch and axed my normal maps. It fixed it. I haven't the faintest idea WHY it fixed it, but it did. Weird pole behavior is almost completely gone now. Shabriri now: Lilitu's north pole: Lesson learned from here on out I guess?

Here's my (current) process. I use GIMP. 1) Do the initial texture painting. 2) Use offset to ensure that the texture tiles cleanly horizontally (vertically is not important for this). New layer from visible. 3) Then, Filters->Distorts->Polar Coordinates This pops up a window like so... 4) Don't mess with the sliders - make sure "map from top" and "to polar" boxes are checked. Apply the distort. 5) What you're seeing now is your north pole, as it will be mapped in KSP. Ignore the stretching around the outsides for now, what you're going to want to focus on is the center. Make your texture look nice and clean around the north pole (for me, this involves a lot of clone brushing). 6) When you're satisfied, run the filter again. This time, uncheck "to polar." This will apply the filter in reverse, bringing you back to a rectangular texture that is now polar corrected for the north pole. 7) For the south pole, flip the texture vertically and repeat steps 3 through 6. 8) I always like to check to make sure it tiles horizontally again at this point. 9) When you're satisfied, this is your color map. I typically do the color map first and then base the height map and biome map off of it so that I don't have to do polar correction again for those. Then, I derive the normal map from the height map. I used to use a "polar correction" plugin I found online, but I found that this does the job better. Here's Shabriri's south pole. There's still a bit of weirdness going on with the sort of "pyramid" at the exact center, but the terrain looks good enough for my liking. Shy of doing it all procedurally, I don't know if I can do much better than that. EDIT 2: This is fixed now, see my next post Lilitu, another moon I've been working on, was a procedural heightmap that I then did a paint over for the color map. It turned out like this... Lilitu also suffers from a little bit of pyramidal weirdness at the extreme poles, but this seems to only be reflected in the ScaledSpace. EDIT: Could this be an issue with normal maps? I recall reading somewhere that Kopernicus didn't like normal maps from SpaceEngine, but can't seem to dig up an explanation for why or what can be done to fix it.

I'd just like to say thank you for this. I'd been digging for hours looking for an answer as to how other planet makers do polar correction on their textures. I have a GIMP plugin for it, but it doesn't get it quite perfect so there's always a bit of stretching at the extreme poles. I guess if I want to avoid that problem in the future I'll have to learn this and stop doing hand-painted textures for anything that's not a gas giant - which, in a way, is kind of a bummer, because I was starting to finally get good at them. Anywho, here's what I've been working on. Both of these were hand painted, but I've been wanting to put a few procedural moons in the system for good measure.

All of the Aerotech rockets I have always used pretty plain solid-color parachutes. If Aerotech has a parachute design I'm simply not aware of, I'd be very interested in making that. I grew up on Estes and Aerotech before I got into high power (Giant Leap, PML). I don't have CTI hardware so I pretty much exclusively fly Aerotech reloads nowadays for anything higher than an F. Looking back though, Quest made a pretty cool parachute that I think I could probably do a skin for. I remember having one CRC kit (the Razor, with the tube fins) that I could take a look at the chute for as well. I'm not that familiar with Canaroc, might have to look into them.

Just a quick heads up, this mod is good to go as-is for 1.2.1. No update is required. I just bumped the version number over on Spacedock.

Apologies for the necromancy, but I thought it was more appropriate than making a whole new thread for it. I've updated this mod to be compatible with KSP 1.2 and also did a flavortext and texture pass - you can now tell which color parachute you've got even when undeployed/in editor. New download link in the OP - also should be coming very soon to CKAN.

Having a bit of an issue with the latest version... Going EVA with skins that don't have eyes crashes me, with or without helmet, with or without reflections, every time. They work fine on IVA though. Changing the skin to one that doesn't remove the eyes - no crash. http://pastebin.com/raw/2xpVkxJm

Decided to try out editing the default Valentina skin. I think it turned out pretty well. Doh, the normal map is backwards. I fixed that but forgot to take new screens.

Actually, no. The actual reference is far more interesting than that.

My latest creation! Cheers if you know where this logo is from.

That specific head used a hairstyle from Sylith as a base, so I'd need to get permission before releasing it - or else entirely redo it from scratch. I've sent Sylith a PM about it. I'd love to release it, it turned out great.

Thanks, I'd been struggling with Molly's because she also has a very light-colored hair piece, so either her hair or her barrette was getting flagged as "low" when they should both be elevated. I think I can fix this now by modifying the original texture before passing it through the normal map tool.