Gravitasi

Thanks! I'll put a link to this post on the OP later. I haven't updated the plugin yet, since there are still some things that I would like to change/add on KittopiaTech side. I have experienced this bug since the time of PlanetFactory CE. Not really sure what caused it so far, probably it's a texture memory allocation failure. Fortunately, there's an easy workaround. Just do a quicksave, followed by a quickload. Then, load the configuration again. The texture should be loaded correctly now. Nice! @ All contract-related poster: AFAIK, Kopernicus hasn't added any code for contracts yet. So, it's actually not surprising that there may be some problems on Career gameplay.

Yeah... I had to fix it before you did, so I would not need to make another apology post. Nice info, thanks! By the way, how did you check out the textures of the stock planets?

Gosh... This bug again... Could you (or anyone with the same problem) post some screenshots that show it? Just to avoid some possible misunderstanding, since I haven't experienced/seen it before. Sorry, I honestly have no idea about it... By the way, I've merged your pull request and post a question on the thread. Also, I recently added support for multiple PQS mods. Feel free to test it if you are interested. Thanks for the report. I'll keep it on my possible-bugs-to-squash list. This is what I got from the log: [EXC 09:17:54.834] Exception: Texture "OPM/KopernicusConfigs/SarnusMoons/Textures/Ovok_normal" not found Could you please check whether the texture file is exist? It should be in DDS format. Thanks, I'll check it out later.

Thanks! I'll check it out next weekend... (still busy right now) Okay. I didn't know such plugins exist.

I'm sorry, but I think it's already too late to change any of the planet's name now. In case you didn't notice, this planet pack has already existed for almost a year (at least the PF:CE version).

Nice! Thanks a lot for this... I'll wait for the pull request. By the way, sorry that you have to fix the VoronoiCraters bug yourself; I have some other important stuffs to do lately.

Yes, that's my plan. It will only be an optional module manager config that changes orbital & science properties of all the bodies.

I think he meant that I should move all of the planet orbit to somewhere beyond Neidon, just like in real life (so we will have a complete solar system analogue). In case you don't realize it, all of the planets on the pack are actually real-life analogues to the four plutoids: Putto → Pluto Oorma → Haumea Arane → Makemake Flo → Eris 1. It will work, but not now... We have to wait until OPM team update KopernicusTech to latest version, which I believe will happen in the next release. 2. It was planned on the initial release of PF:CE version, but I remembered there was some technical difficulties, so I decided to drop it altogether... I think I will try to add it again in the future. Thank you, but I honestly believe that there are still a lot of things that needs to be done.

I have added some useful link to the OP. For those who is creating, or will create, planets with the plugin, make sure you already read and understand them. Edit: Sorry, didn't mean to double post here... It usually merges automatically to the previous post.... Weird...

I'm still not sure... The problem is, as I already said in the OP, I only have experience dealing with atmosphere-less terrestrial planets for now (and since they have no atmosphere, they also have no ocean). I haven't got much time to study other parts of the code yet (ocean, stars, etc). Even I could get it working, I'm afraid it won't be in the near future. I currently have some important real-life matters to do right now.

Wow... I never expected this.... Thanks for the review!

Hmm... I think the problem is not exactly that they are not applied to scaled space. But, more specifically, they make GetSurfaceHeight produce incorrect results (i.e. it give terrain height value as if those PQS mods were not there). I believe that they are some kind already-obsolete PQS mods because of this fact alone. And for the VertexHeightOblate, I couldn't get the terrain landable. Did you successfully make it landable? Maybe this is why Krag made some custom PQS modifications, which are analogs of them, in the first place; because they never work correctly. Personally, I discourage their usage on planets, because of what they do to GetSurfaceHeight; it will disrupt all plugins that rely on GetSurfaceHeight function to get terrain height information. But shockingly, contrary to my own recommendation, Pol does use VertexHeightOffset! I honestly don't understand why Squad added it to the moon. It makes some plugins that rely on terrain height information don't work properly. For example, try to use HyperEdit's "Ship Lander" on Pol, with low altitude as input. You will find yourself still very high above the ground! Curiouser, and curiouser.

Thank you! I'll check it out later. Btw, I just remembered about your question on how scaled spaces were generated. KT use the actual terrain height (measured from center of the body, using GetSurfaceHeight function) as basis for scaled space mesh calculation. Here is the function that does it. It simply adjusts radius of each vertices on the mesh, so they will match up with actual terrain on the same coordinate. - - - Updated - - - It looks like that there are some questions that already asked several times (and already have an answer). I think I need to put answers for some common question on the OP. - - - Updated - - - Good to know, then!

I've just checked out and tested OPM 1.5.2 myself, and I think I need to clarify some things. First, for the Kopernicus binary files... I know it's hard to believe, but what you actually saw were scaled space generated by KittopiaTech, not Kopernicus 0.0.4. Since you didn't provide any bin files on Kittopia side, it would generate them on game startup, and would replace any scaled space generated by Kopernicus. Even more, you actually don't want Kopernicus-generated scaled spaces, because it didn't have any of your custom PQS modification when generation happened (since all of the PQS modification resides on KittopiaTech side). All of the binary files on Kopernicus\Cache are actually contain scaled space of their respective template planets. Hope that clarifies some things. By the way, what kind of problem are you having right now with KopernicusTech v0.121? I have updated OPM 1.5.2 with KT v0.121, and have generated scaled space for all of the planets, and I have to say that I didn't see any problems (at least not yet).

No, I don't think I could, since you were absolutely right. Sorry guys, I didn't realize that KopernicusTech still needs DDSLoader, even if you don't use DDS textures on the planets; I'll fix it in next release. For now, as already said by sdj64, simply put the DDSLoader plugin in GameData folder, along with latest version of KopernicusTech. It should fix most of your problem.

I have updated KopernicusTech that has Kopernicus 0.0.4 integrated. Please test the newest version, and tell me any problems that you have experienced.

Yes, I think we are, technically, maintaining two version of Kopernicus. But no, I don't think making a pull request will make sense, since all I did was making Kopernicus more compatible with KittopiaTech. I believe Kopernicus team themselves is more interested on creating their own, less hacky, PQS loader. So far, not much changes, actually. Rather than changes, I actually removed some features on Kopernicus, since KittopiaTech also handles it, and it would be redundant if both of them handled it (e.g. scaled space generation). This is also another reason of why making a pull request won't make sense. But of course, if I ever find something that could improve Kopernicus (but not necessarily KopernicusTech), I will make a pull request to the official version. That's a pretty good idea... But there are quite a lot of items in my to-do list right now, so yes, I'm afraid it will take some time... I'm not... so sure right now... How were those configs break, by the way?

Weird... As I said in the OP, it should work no matter how large your planet is. Okay, I'll look into it. I just need to multiply a planet's radius, right? (probably by 11) Yes, the SOI parameter seems to get replaced on startup, somehow. I'll also look into it later. To be honest, I'm not even sure about what I did to fix it... Well... You're welcome. There's no way to do it for now, since I hardcoded the resolution on the code. Okay, I'll make it available on the next release. - - - Updated - - - I just noticed that some of you simply replaced the Kopernicus dll in the package with the new Kopernicus 0.0.4 dll. I need to remind you that Kopernicus code was also modified in KopernicusTech, so there could be problems if one uses the original Kopernicus dll. I'll integrate the new Kopernicus code ASAP. But, since the biome fix is a very long-awaited update, I could understand your enthusiasm, though.

Hmm... That's strange... So far, I have no idea... Btw, I agree with you; it has a great potential to add more detailed surface to planets. Okay then, I'll investigate it later. Unfortunately, multiple PQS mods are currently not supported. This bug was already exists on the original KittopiaTech, as far as I can tell. I have to find a way to uniquely specify the duplicated PQS mods. They were exported; but I deleted/moved the scaled space textures after the exporting process. Maybe this post could give you more information.

Thank you so much for the fix! Can't wait to merge the latest code into KopernicusTech; this is so exciting!

Some good news: I think I can get DDS textures working on KittopiaTech. If using DDS textures is really important for you, I suggest that you postpone the next version release, until I release an update for KopernicusTech (most likely a week from now; two weeks in the worst case).

Hmm... I'll consider it. But first, I have to check whether there are any technical problems if lower texture resolutions are used.

Oh, I see it now... I think there's nothing technically wrong with it; it just that all people (including me) simply didn't know your intention. Personally, I just followed what others have already done on their planet pack (i.e. put everything on Kopernicus folder), so please don't blame me on this. Guess I need to modify the example system (Trans-Keptunian) in order to comply with your original intention, and suggest planet modders to do so too. Thanks for the info!

I assume you have checked the "Export" checkbox before generating the scaled space. Have you moved the generated normal map in KittopiaSpace/Textures/ScaledSpace to Kopernicus/Texture? Okay, I think I'm responsible to give you all a more detailed information about it. Besides the bin file, there are a few textures that will be generated in the directory: colourMap.png: Texture of the scaled space. So far I found it's usually the same as the texture you assign on VertexColorMap; If there's no difference between them, just delete it and use the existing one as scaled space texture. heightMap.png: The actual height map of the planet. Do not replace your height map texture with this. It's just there to provide more information/customization. You could use it to create your own normal map, or a height-based biome map. bumpMap.png: The normal map of the scaled space. For now, it was generated by a simple algorithm, which uses the height map as input (thanks Krag). Use this only if you don't know how to generate a normal map (or don't care much about them). @CaptRobau: By the way, IIRC, you already use the "grayscale" format for the normal maps. I suggest you to use that format instead. I don't know how you generated them, but maybe you could use the heightMap.png in the process. Edit: Oh, I almost forgot. You only need to generate the bin file on terrestrial planets. It is not necessary to generate scaled space on gas giants/stars. Edit2: As of version 0.12, you can change the resolution of the generated scaled space texture by modifying mapFileSize parameter on PQS setting.

Have you generated the scaled space binary file? Scaled space generation is a quite expensive process, so I highly recommend you to generate it beforehand. Or else, KT will generate it for you on game startup (without writing it to the file; only resides in memory), which could introduce some crashes. Then again, I think, in the next version, I will make the scaled space not working, unless you have generated the binary file. I'm sorry, but it's too dangerous to leave them not generated. Actually, this is what Krag did on his PFCE. For the star problem, could you post the KSP.log file? There could be problems when using high resolution PNG texture. Maybe it will work if one use DDS format, but the format is not yet supported...