MrHappyFace

For the "bubbly hydrogen looking surface," Do you mean something similar to the procedural gas giants, except for stars? As for flares, I don't plan on implementing custom lens flares until 1.1 anyways, because 1.1 uses Unity 5, and Unity 5 allows the exporting of AssetBundles in the free version, and people could just make their lens flares in unity and export them in a .assetbundle file. Not sure about solar prominences. It seems like they'd be difficult to implement, especially considering that they would just be eye candy.

Do you mean that the kerbal doesn't move throughout the animation? You need at least 2 keyframes for there to be any movement at all. Either way, it's supposed to take the entire timeline for the animation to play, thats what the timeline is for. If you want to make the animation shorter, edit the duration in the Properties window. I'm not sure what you do, but this is generally what I do when I need to make an animation: Open the animation suite. Before posing, immediately create 2 keyframes at the beginning an end of the timeline. This way, the kerbal will smoothly transition from and to their regualr pose. Then, create a keyframe somewhere in between those 2 keyframes, and pose. Play animation. Keep in mind that to create a keyframe, you: deselect the selected keyframe (if there is one) drag the timeline to where you want the new keyframe Click the Add Keyframe button Pose kerbal Deselect the recently added keyframe to save it

The orange keyframe is the currently selected one. If there is no selected one, either create a keyframe if there are none, or click on the blue one you want to animate. After you've selected a keyframe, just pose the kerbal and deselect the keyframe (click it again) when you're done. It's not the most intuitive system, but it works.

At the moment, I have no plans to implement my own volumetric cloud system. I don't really see the point of remaking something that's already been made. I am, however, going to be making particle based winds, if that interests you.

So I spent most of the last few days on a new feature, which I'm very happy about: Modular Noise It adds a new PQS Mod to the game that allows you to mix noises together in virtually unlimited ways, by exposing almost all of LibNoise's (KSP's noise library) API to config files. I'm sure KillAshley is going to love this... I put together a tutorial for it here: First, an example config: PQS { Mods { ModularNoise { enabled = true order = 10 deformity = 10000 finalNoise = PerlinNoise1 Noises { NOISE { name = PerlinNoise1 type = Perlin frequency = 8 lacunarity = 2 persistence = 0.5 octaves = 5 seed = 123456 } } Operators { MULT { order = 0 applyTo = PerlinNoise1 X = 0.2 } } } } } Let's go over each component of this config: The first 2 lines are lines included in every PQS mod, whether it's enabled, and what position, or order, it is in the PQSMod list. Next, there's the deformity property. It's the same as the deformity property in other PQSMods, It just determines the maximum height that this PQSMod's terrain will reach; in this case, 10 kilometers. Now something interesting: the finalNoise property. It says which NOISE node is used to calculate the final value, which is then multiplied by deformity, and applied to the terrain. Next, there's a Noise node, which can contain and arbitrary number ( ≥ 1 ) of NOISE nodes. This is basically a list of all the NOISE objects you can use. I'll explain it more later. NOISE nodes describe NOISE objects. This config only has 1 NOISE object, which is named PerlinNoise1. You probably noticed that PerlinNoise1 is also what the finalNoise property is equal to. That means that the terrain is deformed based on whatever value is taken from PerlinNoise1. Inside the NOISE node, there is a type and a name property, and some others. The most important property is the type. There are 6 types of noise supported at the moment: Perlin noise Billow noise RidgedMultiFractal noise Voronoi noise Const noise ExDistPerlin noise IMPORTANT NOTE: NOISE objects always return a value between 0 and 1, before operators are applied. Noise Types Perlin: Perlin noise is just simple perlin noise. It looks like this: It has 5 properties: seed: an integer between 0 and 2,147,483,647. The same seed will always output the same results. octaves: an integer between 1 and 30, determines how much detail is generated. The greater the number, the slower the terrain will generate, and the laggier your planet will be. Try to keep it below 8, but a value of 4 or 5 will suffice for most purposes. frequency: a number greater than 0 which determines how close together features are generated. lacunarity: a number greater than 0 which determines how much smaller features in one octave will be than the previous octave. The default value is 2 persistence: a number between 0 and 1 which determines how large features in octaves will be compared to the previous octave. The default value is 0.5 These 5 properties are also used in Billow, RidgedMultiFractal, and ExDistPerlin noise types. Billow: Billow noise is just perlin noise with an absolute value function called on it. It looks like this: It has the exact same properties as Perlin noise. RidgedMultiFractal: RidgedMultiFractal noise (sometimes spelled RiggedMultiFractal) is a noise type that is very good for mountains. It looks like this: It has the same properties as Perlin noise, except you don't need to set the persistence value. Const: Const noise isn't actually noise, it's just a constant value. It looks like this: It has 1 property: constantValue: whatever the constant value is. It can be any real number between -10304 and 1030. It's recommended you stay between -1 and 1 Voronoi: Voronoi noise is very intersting. It's used to generate the Mun's procedural craters, among other things. It can have 2 distinct looks, depending on how you configure it: This: And this: It has 4 properties: seed: an integer between 0 and 2,147,483,647. The same seed will always output the same results. frequency: a number greater than 0 that determines how large the cells are. Similar to the frequency property in Perlin noise displacement: a number between 0 and 1. determines how much cells are offset. voronoiUseDistance: a true/false value that determines which one of those looks the noise will have. True will use the second one, and False will use the first one. Keep in mind that if you don't have voronoiUseDistance set to true, there will be sudden changes in terrain height, which can result in really ugly cliffs. ExDistPerlin: ExDistPerlin (short for Exponentially Distributed Perlin) is a derivative of Perlin noise, created by a professor at UNT, which is exactly the same as Perlin noise, except for the fact that instead of having linearly distributed gradients, it has exponentially distributed gradients. This means that terrain features will be less evenly spaced, and will more closely model real life terrain. I highly suggest you look at the linked page, because the images explain it better than me. image coming soon... It has the same properties as Perlin noise, but with one extra property: mu The mu property determines how the terrain features are distributed. A higher mu value means that there will be more flatter terrain, and less mountainous terrain. The default value is 1.0146, and a value of 1 is the same as regular perlin noise. Operators After the list of NOISEs, there is another list, called Operators, that contains all of the operators used. An operator is a basic function that can be applied to a NOISE object, such as MULT (multiplies it by X) or CLAMP (clamps the noise value between two values). Every operator has at lease 2 properties: order: the order in the list this operator is in applyTo: the name of the NOISE object this operator affects. Operators can only affect this NOISE object, even if it uses 2 or more NOISE's. In the example config, there is one operator, a MULT operator, which is in order 0 (is executes first) and it applies to PerlinNoise1. There are currently 15 operators supported: ADD MULT MIN MAX EXPONENT ABS CLAMP CURVE DEFORMITYCURVE LATITUDECURVE LONGITUDECURVE SCALE TURBULENCE BLEND SELECT I find that all of this is best explained with a flowchart: This flowchart depitcts the config below PQS { Mods { ModularNoise { enabled = true order = 10 deformity = 8000 finalNoise = Blender Noises { NOISE { name = PerlinNoise1 type = Perlin frequency = 8 lacunarity = 2 persistence = 0.5 octaves = 5 seed = 123456 } NOISE { name = RidgedMultiFractal1 type = RidgedMultiFractal frequency = 3 lacunarity = 1.6 octaves = 6 seed = 654321 } NOISE { name = Blender type = Const constantValue = 0.4 } } Operators { ADD { order = 1 applyTo = PerlinNoise1 X = 0.2 } ADD { order = 1 applyTo = RidgedMultiFractal1 X = 0.6 } BLEND { order = 2 applyTo = Blender firstNoise = PerlinNoise1 secondNoise = RidgedMultiFractal1 } } } } } In the flowchart, rounded rectangles are NOISE objects and ovals are operators. ADD: The ADD operator is a simple operator that adds a value to a noise. It can also add one NOISE's value to it's own value. It has 2 properties: applyFrom: the name of a noise to add to applyTo's value. It will also normalize the two values, meaning that if applyTo and applyFrom are equal to 1, then they will still be 1, because they were normalized. X: If applyFrom is not set, then X is added to applyTo's value instead of applyFrom. It is a number that can have decimals. NOTE: You can do subtraction by using a negative X value in this operator, or by using a MULT operator on applyFrom's NOISE object, with an X value of -1. MULT: The MULT operator is a simple operator that multiplies a value to a noise. It can also multiply it's own value by another NOISE's value. It has 2 properties: applyFrom: the name of a noise to multiply with applyTo's value. X: If applyFrom is not set, then X is added to applyTo's value instead of applyFrom. It is a number that can have decimals. MIN: The MIN operator is an operator that selects the minimum of 2 NOISE object's values. It has 1 property: applyFrom: the name of the second NOISE object. Keep in mind that this will only affect applyTo's value, and not applyFrom's MAX: The MAX operator is an operator that selects the maximum of 2 NOISE object's values. It has 1 property: applyFrom: the name of the second NOISE object. Keep in mind that this will only affect applyTo's value, and not applyFrom's NOTE: If you want to set a minimum or maximum hard value for a NOISE object, use CLAMP. EXPONENT: The EXPONENT operator is an operator that sets applyTo's value to the power of either X, or applyFrom's value It has 1 property: applyFrom: the name of the second NOISE object. Keep in mind that this will only affect applyTo's value, and not applyFrom's X: the hard value that will be used if applyFrom is not set. ABS: The ABS operator is an operator that puts applyTo's value though an Absolute Value function. This operator has no extra properties. CLAMP: The CLAMP operator is an operator that clamps applyTo's value between a minimum and a maximum. It has 2 properties: min: the minimum value max: the maximum value NOTE: Keep in mind that the minimum should be less than the maximum, or else things will break. CURVE: The CURVE operator is an operator that puts applyTo's value though a curve. The curve should be in the shape of whatever prominent terrain feature you need. If your curve looks like the image below, then your terrain will have plateaus. It has 1 property: Curve: the curve that this noises's output will be put though DEFORMITYCURVE: The DEFORMITYCURVE operator is an operator that allows you to modify the deformity based on the preexisting height of the terrain. This way, you could make a noise that only gets applied in high areas. It has 1 property: DeformityCurve: the curve that this noises's output will be put though LATITUDECURVE: The LATITUDECURVE operator is an operator that puts applyTo's value though a curve, based on it's latitude. This allows you to have the poles of the planet (or some other arbitrary latitude range) not affected by this noise at all. It has 2 properties: LatitudeCurve: the curve that this noises's output will be put though, based on the latitude LONGITUDECURVE: The LONGITUDECURVE operator is an operator that puts applyTo's value though a curve, based on it's longitude. This allows you to have a range of longitudes on the planet (or some other arbitrary latitude range) not affected by this noise at all. It has 2 properties: LongitudeCurve: the curve that this noises's output will be put though, based on the longitude SCALE: The SCALE operator is an operator that pertubes applyTo's value so that you can It has 3 properties: XScale: the scale along the X axis. YScale: the scale along the Y axis. Larger values will squish the planet's terrain pole to pole, and smaller values will stretch it. ZScale: the scale along the Z axis. NOTE: this does not actually stretch or squish the planet itself, just the terrain's shape. It's not a replacement for VertexHeightOblate. TURBULENCE: The TURBULENCE operator is an operator that randomly pertubes applyTo's value. It has 6 properties: seed: the same as a NOISE object's seed frequency: the frequency of the pertubations. smaller values will result in larger scale pertubations. lacunarity: the same as Perlin noise's lacunarity value. the default is 1.5 persistence: the same as Perlin noise's persistence value. the default is 0.5 roughness: an integer between 1 and 30. a good value is 3 or 4. similar to Perlin noise's octaves value. power: a number greater than or equal to 0 that determines how powerful the pertubations are. A good value should be between 0 and 0.5. anything more, and there are diminishing returns. 0 means that the pertubations don't appear. NOTE: this is the most resource intensive operator. Use it with care. BLEND: The BLEND operator is an operator that blends two noises together into applyTo's value. It selects between the 2 values using applyTo's value, so if applyTo's value is 0.4, it samples the first noise at 40%, and the second noise at 60%. This is where Const type NOISE objects are most useful, because you can use them to have a constant blend between the two values. It has 2 properties: firstNoise: the name of the first NOISE object secondNoise: the name of the second NOISE object It looks like this: In that image, the bottom noise is applyTo, and the other two are firstNoise and secondNoise. SELECT: The SELECT operator is an operator that blends between two noises based on applyTo's value. It selects between the 2 values using applyTo's value. It has 5 properties: firstNoise: the name of the first NOISE object secondNoise: the name of the second NOISE object falloff: how large the gradient between the two noises is. min: the minimum value for secondNoise to be set max: the maximum value for secondNoise to be set It looks like this: In that image, the bottom noise is applyTo, and the other two are firstNoise and secondNoise. Images from http://www.draw.io and http://libnoise.sourceforge.net Also, to avoid a double post... I'm not sure what's going on there, but it looks like an issue with the texture rather than the shader. Try converting the image to a .png file. If you had a texture with solid colors like that, then you'd get that look. Also, KopernicusExpansion does not officially support Kopernicus 0.4 yet. This is in development, so don't expect perfection. For what it's worth, send me your output_log.txt folder (found in KSP/KSP_data/ folder) and I'll see what might have happened

You should only have code in OnStart that needs to happen for every vessel, that way you don't run into any issues. In OnUpdate, there can be code that only happens for the active vessel, and code that happens for every vessel, like this: public override void OnStart(StartState state) { //onstart code } public override void OnUpdate() { // whatever code you need to run on every vessel if (!vessel.isActiveVessel) { return; } // whatever code you need to run on only the active vessel } There's also the GameEvents class, where you can listen for events to see if the active vessel changes, like this: GameEvents example: [KSPAddon(KSPAddon.Startup.Flight, false)] public class GameEventSubscriber : MonoBehaviour { void Start() { //this event is the onHideUI event (activated when F2 is pressed to hide the UI) GameEvents.onHideUI.Add (OnHideUI); } void OnDestroy() { //this part is important too! GameEvents.onHideUI.Remove(OnHideUI); } void OnHideUI() { Debug.Log("OnHideUI"); } }

It should work fine with EVE, in fact they compliment each other nicely, according to what I've heard.

KopernicusExpansion is already supported by OPM right out of the box. Just download it from the forum thread (link in my sig), or CKAN, and you'll have the procedural clouds.

It's all done outside KSP right now. There is an updated, albeit buggy, version of Kopernicus-specific version of Kittopia, but it doesn't have a config exporter yet.

You should only ever use Kopernicus, seeing as it's the one that basically every planet pack uses, including OPM, New Horizons, Arkas, Asclepius, etc. There are also the example configs, which are probably the most helpful source for Kopernicus (besides other people): https://www.github.com/Kopernicus/KopernicusExamples/ Some basic steps to get started: 1. copy over one of the examples (cfg, textures, everything) from the Creating New Bodies folder, and make sure all of the files have the same folder path relative to your gamedata as it is in the github repository. 2. tweak a few settings in the config. 3. run KSP That should get you started, but there are many different ways to go about making your planets, including generating them procedurally, using height and color maps, etc. There are a million and one settings you can tweak, and coupled with all of the nuances of Kopernicus, and the very minimal documentation, It's sure to be a bit of a headache to start. If you have questions, you can ask the people over in the kopernicus forum thread, they'd be happy to help you.

My suggestion is to have less craters, and more noise. The first image looks much better in my opinion. Also, what monitor are you playing on that you need your screenshots to be so square-shaped?

In TR, there should be an action in the Kerbal's rightclick menu that is for toggling the helmet. Just use that, I don't see why the space center GUI has anything to do with it. EDIT: Apparently, there isn't a button in TR that does that, either I'm misremembering, or it was removed at some point. Anyways, another fix I found is entering/exiting a pod, so you can do that if you don't want to leave the flight scene.

In the editor, there's a button to toggle the helmet, and I have it automatically set the helmet back to enabled when you exit the animator, so that your kerbals don't accidentally have incorrect helmet info. You should probably just turn the helmet back on with TextureReplacer before animating, and use that button if you want to animate with the helmet off.

The "Legacy" UI stuff is still supported, and updated, in 5.x unity versions. They just call it legacy because there's a newer system now.

yes, the UID is random, its a Guid. As long as there are no duplicate UID's in your persistence file, you should be fine. not sure no, the order does not matter no idea

This was announced in today's devnotes. It seems like it might fix some of the bugs animating the face that we've been experiencing.

That's a pretty neat idea, I'll probably use it, thanks. However, instead of making it only appear up close, I could just use particles. Grass is usually done with billboard textures, and particles ARE billboard textures, plus they're really, really optimized, so rendering thousands of them at a time wouldn't be a problem. I'd just need to manually position the particles, which isn't actually that hard. There is even support for UV animated particles, so waving grass could be done too. I agree, the current implementation of ground scatter kind of sucks, and Kopernicus's implementation for configuring them is even worse. Don't really know what to do about that though, I don't want to have to entirely rewrite LandControl just so I can have better scatter, and I can't really modify the stock code for scatter... Hmm

You could recolor the Joolian moons, so they match better with the Jool recoloring. Vall -> Europa Tylo -> Ganymede Bop -> Themisto Tylo would become browninsh-grey, to better match Ganymede, and Vall would become white with some brownish coloring like europa has. Bop becomes Themisto because Themisto is a small moon that orbits at a high inclination, very close to the Galilean moons, just like Bop does. We haven't seen Themisto up close yet, but it's albedo indicates a dark grey color. Laythe and Pol don't have very good Jovian analogues that I know of.

Is this a stockalike recreation of our own solar system, I'm not sure? It looks pretty cool. Also, is it going to be 10x scale like RSS, or stock sized?

I second this. It would be really helpful if this could work for Xamarin.

Every time you ask, I push it back by a week Next time, please don't ask generic Kopernicus questions in this thread, I answered you in the Kopernicus thread: http://forum.kerbalspaceprogram.com/threads/114649?p=2221230#post2221230

How can I see the source code? It looks like the part module is a part of USI_Tools, but USI_PulseDrive.cs nowhere to be found on the github repository.

You shouldn't even be using Unity 5 until 1.1 comes out, but I imagine that it's in the best interests of Squad to make sure that PartTools are compatible. If it wasn't they'd have to re-part-tool-ify all their parts.

Here's a relevant thread on that: http://forum.kerbalspaceprogram.com/threads/135480-Help-with-dual-side-Solar-Panel-(Blender-Unity)?p=2220924#post2220924

I particularly liked the nyan cat that appeared in ModuleManager on April 1st. Also liked KSI Placement Services: http://forum.kerbalspaceprogram.com/threads/123707