Teknoman117

Happened to notice @Thomas P. mentioned Kopernicus. Bryce Schroeder (the other guy that started it) and I had quite a vision for Kopernicus when we started it, part of it was that I needed a break from some crappy contract work I got myself involved with. Unfortunately after a few months I was back at university and I had no time to work on the mod, and Bryce was trying to finish his master's degree. I left it for a bit and it stagnated, which means we ended up with a cobbled together solution (anyone remember KopernicusTech?) of a few different mods that only worked so well together. Personally, I felt a bit flustered seeing KopernicusTech, not because I was upset about people using my code (I lost that right when I uploaded everything to the internet for free), but rather that my vision of a well designed, no compromises on quality mod had become what it had become. This wasn't meant to insult anyone who was working on it, but we all have to agree it was a stop-gap until something better came along. When we originally set out to create Kopernicus, the only other "planet adding" mod was Planet Factory, which while it functioned, was a very "hacky" solution. It was also released under a restrictive license ("no modifications of this source without my explicit approval" kind of thing). Since the developer disappeared, this meant we had to start from scratch, although I will admit I looked at the source for some hints into how some things worked. We knew that since Kopernicus had a significant potential to become a large mod in the community, if either or all of us had to deal with real life, we didn't want others to have to start from scratch. This is why we chose to release Kopernicus under the LGPL license. Regardless of how we "felt" about things, development could continue. Needless to say, ~a lot~ of people shied away working on Kopernicus because the PSystem replacement Kopernicus uses is arcane and undocumented at best. Especially after having to fool Unity into doing some strange things (I spent 2 weeks attempting how to create prefabs at runtime). Either way, when Thomas came along and wanted to take over development, he made a fork and submitted some pull requests to change things. After talking to him for a few weeks he seemed to understand what we had wanted to do with it so I gave him access to the main repository. That was a bit over a year ago now. I was wholly ecstatic that someone wanted continue where we left off, because I really wanted this mod to be a thing but I myself was trying to finish my degree, and I couldn't afford any distractions (I'm graduating in a month finally, and got a job at Sony Computer Entertainment America (the playstation people)). Either way, this is basically my thoughts on the matter. Everyone who is modding KSP should be doing out of enjoyment for some reverse engineering and project development. If you're only programming for the fame, you're doing it wrong and eventually will burn out. We're a community here - modding isn't easy, and people tend to enjoy the results. If someone else wants to contribute to your mod, or hell, take it over it you're unable to continue developing it, be happy that someone enjoys your mod so much their willing to contribute their time to it's development. If you see forks of your mod running about and you're intent to centralize your mod for compatibility's sake (basically what i did when KopernicusTech was around), figure out WHY people are forking and having multiple versions. Kopernicus's reason was because the planetary configuration was in one file which belonged to the mod (System.cfg). This sparked the idea to fully support (and require) ModuleManager, which enabled multiple independent planet packs to peacefully coexist in one installation. I went around to the most popular planet packs whose developers would open a dialog with me about supporting module manager, and also consolidated all the Kopernicus forks when the PQS modding system was completed. From what I could tell at the time, none of the developers were upset at this, and it made Kopernicus just that much better. TL;DR - we're all supposed to be doing this for fun. Be happy someone enjoyed your work so much as to contribute to it or attempt to continue to improve it when you're unable. Also, this is a very relevant article in this scenario - http://linuxmafia.com/faq/Licensing_and_Law/forking.html

Thanks, but still having issues. Doesn't seem to work under Mono on Linux, even if I recompile it in .NET 3.5 mode and link against the version of Mono.Cecil that comes with KSP. Edit: Log - http://pastebin.com/HGEy9K6Y

Could someone upload the 1.0.4 compatible patcher tool? I'm having trouble building it myself. It keeps throwing exceptions when running the patches on HighLogic...

What version of Unity does KSP 1.0.4 use? Also, at this point, do we still need to use the angrilov mono lib?

Hey everybody, lets move over to another thread at this point. I haven't spoken to Bryce in months, and I'd rather have control over the thread (so I can put releases in the first post). I've created a new thread http://forum.kerbalspaceprogram.com/threads/114649-0-90-Kopernicus-Pre-Alpha-%280-0-6%29

There is a tentative fix for that bug in the 0.0.6 release. As I personally have no idea what the bug looks like in game, i'm relying on those who saw it to go and test it for me.

This works just fine - - - Updated - - - I'll see if I can track down a tool to convert them to unity normal maps in the morning. Excerpt from the unity forums "However, in all other cases it appears, Unity uses a specialized coding, storing the x-fraction in a, and the y-fraction in g. red and blue are ignored. I guess this is done to allow encoding of 16bit normal maps, where it would store the 16bit x-fraction in b+a, and the y-fraction in r+g."

Kopernicus may have cached an older scaled space mesh on you. Delete the GameData/Kopernicus/Cache folder to clear them. Or if you're editing the PQS a lot, we currently have a intermediate solution of creating an empty file called "DEBUG" in the Cache folder to prevent kopernicus from loading cached versions.

Lol. I got back out of bed to post that config when I read the KSP forums on my tablet..... - - - Updated - - - Oh, Unity has a different normals format. Dunno why but its stupid. Let me go bug NathanKell, he has a tool I think...

Did you put the example planet folder in a subfolder called KopernicusExamples/ in GameData/? Typing this out makes this seem like a stupid idea...

Yup, it's all i did. I substituted for my own textures for testing purposes, but here's the config changed as above. https://gist.github.com/Teknoman117/d78888940cc3fe35553c Could you just install the base config of kopernicus (no mm, updated System.cfg, updated DLL) with no mods and see what happens? If the kopernicus log is still borked then something is wrong with Kopernicus or your KSP install is damaged.

Yes, you can have any folder structure under PluginData/ that you want. Anything that is a subdirectory/file of PluginData/ is ignored by the game's loader. - - - Updated - - - Pre-Alpha 6 (0.0.6) is released https://github.com/BryceSchroeder/Kopernicus/releases/tag/pre-alpha-06 - - - Updated - - - I've looked over the planet config and found a few errors. When specifying textures and maps, drop the GameData/ prefix, it's assumed by the mod. Also, in the flatten ocean PQS mod config, you specified "falsed" not "false". This caused an exception. After those changes it fired up just fine on 0.0.6.

I think I solved this, check out the development dll. You'll also need to grab the updated System.cfg. Basically I just wrote a custom material for the moon that mimics the Mun's material except for the bits that were causing problems (globalDensity parameter) https://github.com/BryceSchroeder/Kopernicus/tree/development/Distribution Could you post the Kopernicus.log, the log of whatever body you made, and the config? You can find them in KSPRoot/Logs/. I've added a custom logging system which outputs a default log for the mod and per body logs during loading so you can see what happens.

Just want to nail down this stupid issue with the Mun surface being black. I've narrowed it down to an issue with the Mun's material itself. I've written my own material definition (in System.cfg) for it using Kerbin's material as a source, and the surface is then not black. So I'm stepping through everything bit by bit to see if I can figure out whats going on. If you want to try it out, there is a current development dll in the git repository under Distribution/. Some examples are in there as well, so don't install everything in the KopernicusExamples/ folder unless you want some strange changes .

So here's a fun revelation. so for me at least, if you land on the Mun and kill and restart the game, going back to the ship through the tracking station causes the Mun to be black. If you use something like HyperEdit and drop yourself into orbit around the Mun, it works. Land and everything is fine, even when you switch back to the previous ship. So strange >.<

Seems to be cause by assigning a clone of the Mun's material in PQSLoader. Take that out and it works fine again. Hmm. Guess I'm not cloning the materials correctly. Also the Mun is the only body to use the Main Optimised shader that *doesn't* have an atmosphere...

I've attempted to address the issue of importing the progress tree here (stock bodies will preserve, custom ones default to generating their own) https://github.com/BryceSchroeder/Kopernicus/commit/bc72f0df09c9157868e665488e36354006314df3 This issue wasn't due to the template bodies having a conflicting flight globals index, but rather due to the fact that the flightGlobalsIndex didn't correspond to the position in FlightGlobals.Bodies[]. This has been fixed https://github.com/BryceSchroeder/Kopernicus/commit/cf233a80a8fc0e190f99353f3c7fa56955eac039 The original goal was (and still is) to provide a method of generating planets without requiring template clones, and to do so before the game starts so the game accepts the custom system. The Template { } config option was provided merely as a convenience for prototyping purposes or if a stock body was *almost* what you wanted. Well, the Linux 64 bit version is stable as stable can be . Honestly the near lack of work (or complete lack thereof) porting an application from Linux 32 -> 64 bit is a testament to how well it was designed. I've done projects where there was no work at all in porting between the two. Hell, most code will compile for different architectures just fine. You just have to follow the design guidelines. Shameless support aside, I do all of my KSP dev work and KSP playing on an Arch Linux 64 bit install.

Nah I think its a bug. Just happened to me >.<

Template free gas giants have been possible since about September. Considering they don't have a PQS...

LandClasses provide tinting colors at different altitude levels What you are looking for is the PQS surface material definition. I hadn't put an example together yet because I haven't figured out how all the options work. Here is a material dump of Kerbin. The property names are the same as the entries you'd put in your config. Ignore the *Scale and *Offset entries, the ksp shaders uses a provided tiling parameter instead of Unity texture scaling. Since this is kerbin, all the texture names are built in textures, which you could use for your planet by specifying something like this "steepTex = BUILTIN/terrain_rock00". You would put this in a Material { } config inside the PQS { } config [LOG 14:21:09]: --------- ---- Surface Material ---- ------------ [LOG 14:21:09]: saturation = 1 [LOG 14:21:09]: contrast = 4 [LOG 14:21:09]: tintColor = RGBA(0.173, 0.173, 0.173, 0.482) [LOG 14:21:09]: powerNear = 0.75 [LOG 14:21:09]: powerFar = 0.75 [LOG 14:21:09]: groundTexStart = 0 [LOG 14:21:09]: groundTexEnd = 10000 [LOG 14:21:09]: steepPower = 4 [LOG 14:21:09]: steepTexStart = 10000 [LOG 14:21:09]: steepTexEnd = 100000 [LOG 14:21:09]: steepTex = terrain_rock00 (UnityEngine.Texture2D) [LOG 14:21:09]: steepTexScale = (1.0, 1.0) [LOG 14:21:09]: steepTexOffset = (0.0, 0.0) [LOG 14:21:09]: steepBumpMap = Cliff (Layered Rock)_NRM (UnityEngine.Texture2D) [LOG 14:21:09]: steepBumpMapScale = (1.0, 1.0) [LOG 14:21:09]: steepBumpMapOffset = (0.0, 0.0) [LOG 14:21:09]: steepNearTiling = 1000 [LOG 14:21:09]: steepTiling = 100 [LOG 14:21:09]: lowTex = terrain_sand00 (UnityEngine.Texture2D) [LOG 14:21:09]: lowTexScale = (1.0, 1.0) [LOG 14:21:09]: lowTexOffset = (0.0, 0.0) [LOG 14:21:09]: lowBumpMap = Waterbump (UnityEngine.Texture2D) [LOG 14:21:09]: lowBumpMapScale = (1.0, 1.0) [LOG 14:21:09]: lowBumpMapOffset = (0.0, 0.0) [LOG 14:21:09]: lowNearTiling = 4000 [LOG 14:21:09]: lowMultiFactor = 10 [LOG 14:21:09]: lowBumpNearTiling = 4000 [LOG 14:21:09]: lowBumpFarTiling = 10 [LOG 14:21:09]: midTex = terrain_grass00_new (UnityEngine.Texture2D) [LOG 14:21:09]: midTexScale = (1.0, 1.0) [LOG 14:21:09]: midTexOffset = (0.0, 0.0) [LOG 14:21:09]: midBumpMap = cloud_normal (UnityEngine.Texture2D) [LOG 14:21:09]: midBumpMapScale = (1.0, 1.0) [LOG 14:21:09]: midBumpMapOffset = (0.0, 0.0) [LOG 14:21:09]: midNearTiling = 4000 [LOG 14:21:09]: midMultiFactor = 100 [LOG 14:21:09]: midBumpNearTiling = 1000 [LOG 14:21:09]: midBumpFarTiling = 100 [LOG 14:21:09]: highTex = terrain_snow00 (UnityEngine.Texture2D) [LOG 14:21:09]: highTexScale = (1.0, 1.0) [LOG 14:21:09]: highTexOffset = (0.0, 0.0) [LOG 14:21:09]: highBumpMap = 05_NORMAL (UnityEngine.Texture2D) [LOG 14:21:09]: highBumpMapScale = (1.0, 1.0) [LOG 14:21:09]: highBumpMapOffset = (0.0, 0.0) [LOG 14:21:09]: highNearTiling = 4000 [LOG 14:21:09]: highMultiFactor = 4 [LOG 14:21:09]: highBumpNearTiling = 2000 [LOG 14:21:09]: highBumpFarTiling = 4 [LOG 14:21:09]: lowStart = 0.02 [LOG 14:21:09]: lowEnd = 0.1 [LOG 14:21:09]: highStart = 0.5 [LOG 14:21:09]: highEnd = 1 [LOG 14:21:09]: globalDensity = -8E-06 [LOG 14:21:09]: fogColorRamp = AerialRampKerbin (UnityEngine.Texture2D) [LOG 14:21:09]: fogColorRampScale = (1.0, 1.0) [LOG 14:21:09]: fogColorRampOffset = (0.0, 0.0) Basically, I don't know whether the low/high Start/End options are related to fractional altitude ((altitude - altitudeStart) / altitudeDelta), or latitude/longitude, etc. I'm pretty sure the midTex range is considered the range between low/high ranges. I would think the steep texture has something to do with slope, but 10,000 is certainly a lot higher of a slope than some of the rocky surfaces we observe on kerbin. Dunno what groundTex is... Also, for something like RSS, you want to drive up the tiling factors to make the surfaces not look as bland. The ocean configuration is the next thing on my list of things to do.

You also have to edit the ScaledVersion (with @ScaledVersion, because every body has a scaled version) and set the type as "Atmospheric" and define the material properties for the atmosphere. Snippet from the FullCustomPlanet example, edited slightly for modifying a stock body (i.e. dropping the scaled space texture modification) @ScaledVersion { type = Atmospheric Material { // Atmosphere settings rimPower = 2.06 rimBlend = 0.3 // Atmosphere color ramp texture Gradient { 0.0 = 0.643,0.220,0.094,1 0.6 = 0.0549,0.0784,0.141,1 1.0 = 0.0196,0.0196,0.0196,1 } } } Atmosphere { // effectively the ambient lighting color for all objects on the ground of this body (provides a slight tint) ambientColor = 0.306,0.187,0.235,1 // // shader.invWaveLength = Color( 1 / r^4, 1 / g^4, 1 / b^4, 0.5); // lightColor = 0.509,0.588,0.643,0 // General atmosphere settings enabled = true oxygen = true altitude = 55000.0 // Atmosphere Pressure // pressure (in atm) = multipler * e ^ -(altitude / (scaleHeight * 1000)) enableLegacyAtmosphere = true scaleHeight = 4.0 multiplier = 0.8 // Atmosphere Temperature temperatureMultiplier = 1.0 }

You can, but I wouldn't recommend it as it drives up the memory consumption. Basically, everything that is unneeded on the GPU should go into PluginData/ to prevent KSP's loader from pulling it into the GameDatabase. I detailed everything in full here (see the edit at the bottom): http://forum.kerbalspaceprogram.com/threads/88168-Early-development-0-24-Kopernicus-Planetary-System-Modifier?p=1806612&viewfull=1#post1806612

I don't think ours is doing that ... basically all I do is turn on the height generating portions of the PQS and sample it at a low frequency to generate the scaled space mesh. Also, Thomas managed to finish enough PQS mods to cover the kopernicus planet. So now it's 95% defined in the config files, only need to write some wrappers around the pqs altitude fade parameters and we'll be 100% configurable.

Added an example for creating 100% custom gas planets with Kopernicus https://github.com/BryceSchroeder/Kopernicus/tree/development/Distribution/GameData/KopernicusExamples/GasPlanet You have to grab the development version to use this at the moment. https://github.com/BryceSchroeder/Kopernicus/tree/development/Distribution - - - Updated - - - Axial tilt is still out of grasp without Squad. Basically, we'd only have to modify OrbitDriver, but since that's a built in construct of KSP, we're still hosed. Edit - actually, it *might* be possible by modifying the layout of the localspace transforms after game load. But it would be very hacky .. and not something I'm too particularly focused on ATM. I also have no idea if this would break any of the other math KSP uses.

Thomas, would be nice if we could specify some affector for the particles. Such as the particle and ion trails of comets being oriented relative to it's velocity and the sun respectively.