Poodmund

As OPM has discrete body references in the configs for the celestial bodies that have not been changed between the official OPM and OPM_Galileo, it should be fine to add to an existing OPM career save. You will want to delete the existing OPM and CTTP folders before installing this mod. However, as with all game changing mods like this, it's probably best to make a backup of your install just in case. EDIT: OPM_Galileo in fact removes the FlightGlobalsIndex body references from the body configs, to ensure compatibility with previous versions of the official release these will have to be edited in to your configs with the values of the old official release configs.

Download Unity 5.2.4f1: https://unity3d.com/get-unity/download/archive (KSP Part Tools work with this version at least) Install r4mon's Float Curve Editor as you linked above into Unity. Read his "How to Use" section in his OP. Copy and Paste your Atmosphere pressureCurve values into the Float Curve Editor window to display the curve. To find the Pressure Half Height, look at the 2nd Value of your first key, this is your 0m ASL Pressure value. Divide this by 2 to get your half-pressure value, then look down your y-axis to find that value and trace is across to the intercept with the curve. Trace that intercept down to the x-axis and it will give you the altitude of the Pressure Half Height in meters. Here it is done with OPM Tekto's atmosphere. Not that Tekto has a atmospheric limit of 95km and ASL Pressure of 124.63kPa. Click to view full res. What we can deduce from that is that Tekto has an atmospheric half height of 5.7745km with an atmospheric limit of 95km.

Does the NetKAN repository get any attention nowadays? EDIT: On a serious note, the NetKAN checks seem to fail if I state a max version of KSP higher than a max version of KSP that a dependent mod states. During the check, it tries to pull the dependent mod at the higher version number of your own mod and therefore fails. i.e. My mod - max version 1.9 Dependent Mod - max version 1.0 NetKAN check - can't find Dependent Mod that is compatible with v1.9; fail. Isn't this bad logic? I have set up my max versioning in this way to ensure that when KSP updates, I do not have to upload a new distribution with a new KSP AVC file to get CKAN to reindex new metadata. Also, thanks Olympic for the merge.

It should be noted that this should be treated as a centralised resource, however, please avoid bloat. It is good practice to submit only textures that you feel will contribute to any shortcomings in the existing pack, will be utilised by multiple mods and that will enrich the mod as a whole. I presume much like Community Resource Pack and Community Category Kit, any submitted textures will be open for discussion on inclusion for a period of time before any decisions on being included within the pack are made?

You can do this with a custom config using Custom Barn Kit

Do what everyone should do when they're having an issue.... post their logs. In this instance, predominantly the Module Manager Cache file but the rest won't hurt: On a different note, Tekto and Thatmo are getting a large second pass on their Scatterer configurations. They will look 10x as nice when transitioning from orbit to surface. Please be aware, however, there is an issue with Scatterer that is causing Null Refs so at this stage you may want to disable the Ocean Refraction setting in the Scatterer settings menu.

Many different ways, some like to hand paint/stitch their together, some like to procedurally create terrain maps and others use programs like Space Engine to do it all for them. I created a thread recently with a lot of resources on Planet Texture Mapping: There is also a Discord server hosted by Gameslinx where members discuss planet making:

@blackrack, I can no longer enter negative values into the Scatterer GUI, when I try to input a '-' character into the GUI it logs a message in the console, "Exception: FormatException: Unknown char: -". The only way to get these values in game is by manually editing the config and reloading it in game. EDIT: Also I am experiencing the issue discussed here around one of the bodies in OPM: https://github.com/LGhassen/Scatterer/issues/28 Did this ever get resolved? EDIT EDIT: Right I think I've narrowed it down and expanded on the info posted on that GitHub issue. Basically, Scatterer will constantly throw Null Refs when you are within the PQS load in distance around any body that does not have an ocean. To replicate this issue load a vessel directly from the Tracking Station (so that the refractionCamera has not yet initiated) that is orbiting within the PQS load range of a body without an ocean i.e. around The Mun at 15km or so. You should see the Null Refs appearing in the console log.

Latest Release - v.0.3.5 "The Matoro" Pre-Release Beta - 23rd Sept. 17 CKAN entry will be updated in due course. Please note, this release was intended to be used alongside Galileo's unofficial OPM_Galileo v1.2.1 release of the Outer Planets Mod. All links to dependent mods can be found in the OP. P.S. Not happy with some of the visuals, these will most likely be changed over time. This is a personal view after working alongside the GPP team. OPM-VO needs to improve.

Basically as said above, DXT1 is fine for bodies that do not feature Ocean modules as the maps do not require an Ocean Mask in the Alpha channel. This will reduce the file size significantly over DXT5.

Hmmm, I was hoping this was not the case but expected as much. Thank you for the confirmation. This is very true. I wish the KSPedia was a more dynamic object based system rather than everything being almost baked into a static asset. Thank you for your help though, Nils. This tool is very useful.

Oh I gathered that yes, I was looking at Surface Experiment Pack and @DMagic committed a file with localization strings for the KSPedia and was wondering if there was a way inside Unity to get it to auto generate the AssetBundle in the various languages by referencing external text files with the different languages in. See: https://github.com/CobaltWolf/Surface-Experiment-Pack/commit/f767c482307d2690d8458d5a41c62db1af8a287f#diff-1af52905758e628e12a23fa9ff7951e8 So to get KSPedia assets translated, people with the linguistic ability and Unity knowledge are required?

@Nils277, is there any documentation is to what is required within the Unity KSPedia files to implement the localization string identifiers?

I honestly have no idea how that works.

Errrr... yeah, as a non-Kerbalism player I've never read over those strings. I don't know what medication Jade was on at the time of writing those. Haha... @JadeOfMaar, any answers? Also as a non-native English speaker, you are of great value to us from an understandability stand point. If it's not clear enough for you, then we should think about rewriting it as it should be readable for all users.

CCK is a framework... community based suggestions as to what mod makers should categorize their more bespoke parts under. FE expands the stock categories but separating the existing stock categories into more discrete categories and also does the same for more popular mods, it also adds in additional categorising functionality so that you can say, select Category: Rocket Motors > Monopropellant to see all rocket motors that only use monopropellant. If you use Filter Extensions, you quickly appreciate that it's a great QoL plugin that is one of those, "can't play without it" kind of mods, whereas CCK is a great framework that is well established that makes sorting parts for users and also the usage with FE easier in the long run. Both are great, both are quite different.

JadeofMaar wrote the majority of the flavour text in the mod and, afterwards as a group, we reviewed most of it to make sure it was coherent. He did a great job with the descriptions. If you find any areas that may be hard to read, have spelling mistakes or grammatical errors please let us know.

@pap1723, I love this contract pack, the implementation is top notch and would love to get it functioning alongside GPP. I fear that due to GPP's system layout that 'Planets' DATA node doesn't really suit the system as you probably well know, the only way around this I can see would to detect if GPP was installed and edit the node and keys inside to suit i.e. @CONTRACT_GROUP:HAS[@DATA:HAS[#type[CelestialBody]],[#title[Planets]]]:NEEDS[GPP] { @DATA { @Mercury = HomeWorld().Parent().Children().ElementAt(1) ... etc. } } ... to reassign the named planet/moon variables to suitable bodies within the GPP system, possibly along the lines of the following: Mercury = Thalia Venus = Gratian (Tellumo would also do but it has no real moon and offers a very low chance of returning from) Earth = Gael Moon = Iota Minmus = Ceti Mars = Niven Phobos = This is difficult as Niven has no moon. Could probably substitute Thalia or Gratian's moon. Jupiter = Otho Would you be interested in getting GPP compatibility incorporated into this contract pack or maybe folding something similar into GPP istelf?

Why not add it in as a late game, Omni antenna?

Removing Polar Pinching/Distortion from your Planet Map textures 1. Grab you texture in your image editing program. For this example I am using the horrid texture that I demonstrated the Horizontal Tiling process on as it will suit the purposes for demonstration of this technique. When wrapped around a sphere this texture will currently not look very pretty at the polar regions as we will see shortly. 2. Select Filter > Distort > Polar Coordinates 3. Ensure 'Rectangular to Polar' is selected and hit OK. 4. Here you can see what the texture would look like on the North Pole if it were wrapped around a sphere; you can tell that the texture is not set up to be spherically wrapped as there is a lot of distortion around the top. This is what is commonly referred to as 'Polar Pinching'. 5. Use all your Photoshop/GIMP/Paint.net etc. skills to remove the distortion and get the center of the image looking nice. Try not to affect much of the texture as it falls towards the outer edges too much, keep your healing towards the center where the predominant distortion is occurring. 6. Select Filter > Distort > Polar Coordinates 7. This time we are applying the inverse distortion so ensure that 'Polar to Rectangular' is selected and hit OK. 8. Here you have distorted the image back to its rectangular format and you can see your polar wrapping occurring at the top of the texture. Now onto fixing the South pole. Flip your texture vertically by selecting Image > Image Rotation > Flip Canvas Vertical. 9. Apply the 'Rectangular to Polar' distortion filter. 10. Here you can see the ugly warping of the texture at the South Pole. 11. Again, use all your Photoshop/GIMP/Paint.net etc. skills to remove the distortion. 12. Apply the 'Polar to Rectangular' distortion filter. 13. Here we have the texture back in rectangular format, but upside down. Flip it back vertically to return it to its original orientation. 14. There we have it, the finished article. Here you can see at the top and bottom of the texture the spherical warping as you are trying to represent a spherical mesh on a rectangular net. Using this texture in game around a planet/moon, it would no longer have distortions or pinching at its North and South poles. 15. Save this final texture as a new image and Copy > Paste it over your Master Copy texture before you started this Polar Pinching Removal process. Feather the top and bottom of the newly distorted image into your existing Master Copy texture image. The reason behind this is that when applying the Polar Distortion filter to an image, you are inducing compression into the texture that, when doing the reverse distortion (to get the texture back to an equirectangular format), you will end up with a texture map that has blurring and artifacts appearing on it. To get around this issue, save you map before hand, do the Polar Distortion Removal process and save the result as a new texture. Copy this new texture over your Master Copy and then feather the pasted, distorted map back into the Master Copy map. By doing this, you will limit the amount of compression you are inducing into your map textures to only the polar regions.This is a side by side, before and after, comparison of the compression of a 4k x 2k map that has been run through the Polar Distortion filter at a 800% zoom to show the result on the pixel level... look at all that horrible compression! Please Note: This finished texture would be pretty terrible to use in-game as it features a heavily directional light source (see shadows/highlights in the craters). It should also be known that it is good practice to generate your colour/albedo maps directly from your post PQS heightmap (i.e. heightmap with the PQS baked in), as this way, you will not be inducing any directional lighting from any references images you use.

Horizontally Wrapping Textures/Tile-able Textures 1. Grab you texture in your image editing program. Here we have a horrible photo from NASA's archives that won't suit a planetary texture but it will suit the purposes for demonstration of this technique. This texture currently does not wrap well around a cylinder as we will see shortly. 2. Select Filter > Other > Offset from the Filters menu. 3. In the horizontal input, type in the half-width value of your image. For example, this texture is 2048px wide, so I have entered 1024 to offset/wrapped around the image horizontally by half. Here you can see how apparent the fact that the image is not horizontally tile-able as we have the stark contrast of the edges of the texture not meeting up in a nice fashion. If the texture was wrapped onto a sphere in this state you would see the highly visible texture seam running from the North to Sole pole. 4. Use all your Photoshop/GIMP/Paint.net etc. skills to remove the join and make it appear that the two sides of the image blend into one at the center. 5. Once finished, go back to Filter > Other > Offset 6. Enter the half-width value of your image to return the texture back to its original horizontal position. 7. There you have it, you have successfully blended the sides of your texture so it can tile/wrap around horizontally forever without being noticeable.

The maintaining of this forum has not been getting the love that it deserves for quite a while now, sans updating to new IPB packages. I wouldn't hold your breath, Regex. I fully agree with the sentiments of this topic though.

The only issue that remains is that the moons still rotate on the ecliptic plane and not on the same axis as their parent planet that has simulated tilt. For OPM-Tilit, Sigma88 adjusted Urlum's moon's textures through 90 degrees and changed the rotational period of said moons to an incredibly large amount to stop this issue from being perceived.

This consideration has been made but this isn't a GPP issue, this is a Kopernicus issue and should be discussed in the appropriate place as such: https://github.com/Kopernicus/Kopernicus/issues/214

Update! I have made a few changes as to how the Relay range/strength is shown if you have a DSN selected as on of the control points. Previously it would return a Relay range of 0m as technically any connection with the DSN is considered as a Direct connection (you can't relay through the DSN)... but this was slightly confusing to in practice as your Relay vessels would show nil Relay capability when connecting back to the DSN. I has been changed to consider the DSN as a valid input when it calculated Relay Control Point power and as such will show >0 Relay range now. It should be more coherent to an end user this way. Secondly, I have added in a new feature that can be seen in Cells J15:P15. You can now select two planets in the system and it will output your Signal Strength capabilities between those two bodies. Really useful if you want to set up a Relay output on an inner or outer planet. Link