[WIP] KopernicusTech - An integration attempt between Kopernicus and KittopiaTech (v0.13 - 03/26/15)

[sdj64]

Every time I try to fix something, more weird crap happens. Now it's got the timewarp restriction, atmosphere bar, and fire effects it would have at this altitude on Eve, but it is completely outside the atmosphere (KER is correct, also look at the orbit, it is almost completely circular from Hyperediting it there.)

I think I'll scrap the config and start over, unless someone can point me in the right direction.

[Teknoman117]

In my case it was because I couldn't change what body Eeloo orbited (from the Sun to Sarnus) without putting it in System.cfg. My vision was impossible without moving Eeloo like that. If you fix that, there's no reason for me to not eliminate the Kopernicus folder for config and texture placement. I personally use a file loader/unloader to move stuff in and out of GameData, so I haven't had to remove files from that folder manually. Other KSPers do, so if I don't have to use System.cfg anymore, I won't and I'll happily switch to a more modular setup that will allow people to easily mix and match other Kopernicus mods with mine.

I think it also doesn't help that the Kopernicus forum OP hasn't changed in months and as such look out-dated. When I started my mod Kopernicus was all but dead or at the very least felt like a in-development version instead of a full package. As such it felt natural to bundle the plugin with my mod to reduce my mod's players from having to scavenge GitHub or the forum thread for the right version, etc. When Kopernicus has had some of its major bugs worked out and eliminates depending on other mods for PQS loading and such, I'd suggest starting a new thread for that version. Then people can download the Kopernicus plugin from that and mods like mine will be like the modular configs for RSS, instead of every Kopernicus-based mod being an island like they are now. That thread would also be a good place to direct modders to tutorials and other information that will help them create planet mods.

Sorry, I probably should've made an example for reparenting. The module manager config for editing an existing value needs to be prefixed with @. So its "@referenceBody = Sarnus". I just tested this in 0.90.0 with Kopernicus ("core" i guess). Worked just fine!

@Kopernicus:AFTER[Kopernicus]
{
    // We want to edit the definition of Eeloo
    @Body[Eeloo]
    {
        @Orbit
        {
            @referenceBody = Kerbin
            color = 1,1,0,1
            inclination = 2
            eccentricity = 0
            semiMajorAxis = 30000000 
            longitudeOfAscendingNode = 0
            argumentOfPeriapsis = 0
            meanAnomalyAtEpoch = 0
            epoch = 0
        }
    }
}

[Borisbee]

No need to call it Core. The confusion came because Augustus had a thread calling a config file "Kopernicus Core". All it did was contain a preexisting config file with all the planets from various planet packs so that flight global indexes weren't used twice. I can see that he was trying to help, but honestly I think it did more harm than good because it's just caused a ton of confusion on what it actually did. Especially since he was packaging the Kopernicus dll along with it.

The planet pack authors should have just checked which flight indexes were in use when making the pack rendering such a thing useless. It's not like there are tons and tons of them floating around anyway.

Random thought, would it not make sense to have Kopernicus itself assign incrementing flight indexes per planet it loads? Would stop this sort of issue in the future.

Edit: Ok you replied while I posted, nevermind heh

Edited February 6, 2015 by Borisbee

[Teknoman117]

I originally wanted to just randomly generate them, but the issue is that they define the ordering in the R&D center ... as well as some other important stuff.

[Borisbee]

I originally wanted to just randomly generate them, but the issue is that they define the ordering in the R&D center ... as well as some other important stuff.

Ah, this information is handy then. I wasn't aware what they were really used for. So it makes sense to have them increment outwards from the sun I guess.

[Teknoman117]

Ah, this information is handy then. I wasn't aware what they were really used for. So it makes sense to have them increment outwards from the sun I guess.

Basically when all the planets are created, the game shoves them all in a list. It then sorts the list by the flightGlobalsIndex, and the resulting position is the reference body id used in the rest of the game. However, there are some issues with haphazardly redefining them. For some reason (well, it carried over from old versions of the game), Kerbin is flightGlobalsIndex 0, the Sun is 1, and the Mun is 2. If any of those are redefined strange things break in the game. Like not being able to recover ships and stuff.

[Gravitasi]

Either way, I'm a little curious - a lot of these planet packs I've been browsing though cram everything in the Kopernicus folder - it's *supposed* to support module manager, textures and configs don't have to be put in the Config folder of Kopernicus. Everything was just supposed to be a module manager script editing the Kopernicus config. If it is broke PLEASE TELL ME!!! The idea was to be able to have planets / planet systems potentially be their own mods so you could mix and match planet packs. (Well, those who run KSP on Linux 64bit could anyway, as it's the only stable 64 bit version =P )

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!

Edited February 6, 2015 by Gravitasi

[CaptRobau]

No need to call it Core. The confusion came because Augustus had a thread calling a config file "Kopernicus Core". All it did was contain a preexisting config file with all the planets from various planet packs so that flight global indexes weren't used twice. I can see that he was trying to help, but honestly I think it did more harm than good because it's just caused a ton of confusion on what it actually did. Especially since he was packaging the Kopernicus dll along with it.

The planet pack authors should have just checked which flight indexes were in use when making the pack rendering such a thing useless. It's not like there are tons and tons of them floating around anyway.

Random thought, would it not make sense to have Kopernicus itself assign incrementing flight indexes per planet it loads? Would stop this sort of issue in the future.

Edit: Ok you replied while I posted, nevermind heh

Core also collected PQS data in RealSolarSystem.cfg, which I don't remember being well set up for ModuleManager like configs. So it had a function.

[CaptRobau]

Sorry, I probably should've made an example for reparenting. The module manager config for editing an existing value needs to be prefixed with @. So its "@referenceBody = Sarnus". I just tested this in 0.90.0 with Kopernicus ("core" i guess). Worked just fine!

@Kopernicus:AFTER[Kopernicus]
{
    // We want to edit the definition of Eeloo
    @Body[Eeloo]
    {
        @Orbit
        {
            @referenceBody = Kerbin
            color = 1,1,0,1
            inclination = 2
            eccentricity = 0
            semiMajorAxis = 30000000 
            longitudeOfAscendingNode = 0
            argumentOfPeriapsis = 0
            meanAnomalyAtEpoch = 0
            epoch = 0
        }
    }
}

I've gotten my planets working using this approach, but I noticed that in KopernicusTech (the version you created for me was based on 1.4 which still used RSS) that an atmospheric planet that I had been working on starting glitching out. It's a terrrestrial planet with an atmosphere and oceans. Once I get low enough the oceans don't show up like they normally do and once I get even closer the entire planet starts to fade out. Once I get even closer, a bright flare appears. All I've done is move it over from non-modular, everything in System.cfg, etc. to non-modular so it seems to be related to that.

[_Augustus_]

I've gotten my planets working using this approach, but I noticed that in KopernicusTech (the version you created for me was based on 1.4 which still used RSS) that an atmospheric planet that I had been working on starting glitching out. It's a terrrestrial planet with an atmosphere and oceans. Once I get low enough the oceans don't show up like they normally do and once I get even closer the entire planet starts to fade out. Once I get even closer, a bright flare appears. All I've done is move it over from non-modular, everything in System.cfg, etc. to non-modular so it seems to be related to that.

Huh. I don't have that bug with Erin.

Edited February 6, 2015 by _Augustus_

[Borisbee]

So, it seems to by the case that unless you use Mun as your template body, attempting to use VoronoiCraters makes the planet disappear. I'm sure this is because Mun is the only body to use craters so naturally it works there, but I'm wondering if someone with more knowledge on the PQS system could tell me a theory on why it doesn't work when trying to apply to a different body. Frustrating to not be able to use them on bodies since they are great for adding little detail to what might be an otherwise boring surface.

[Candlelight]

Photo editing is so fun.

http://i.imgur.com/mVM0Qta.png

http://i.imgur.com/4PU4Jel.png

How...do...you...make...these...glorious...pictures...?

- - - Updated - - -

Does anyone of you have a guide on how to use KopernicusTech?

I would really appreciate that.

[Borisbee]

How...do...you...make...these...glorious...pictures...?

- - - Updated - - -

Does anyone of you have a guide on how to use KopernicusTech?

I would really appreciate that.

Just look at the example planets. It should be straight forward to figure out.

[_Augustus_]

How...do...you...make...these...glorious...pictures...?

- - - Updated - - -

Does anyone of you have a guide on how to use KopernicusTech?

I would really appreciate that.

Lol, used Paint.Net with a few addons.

And use my PF planets as templates! I have mapdecals and everything working.

[MoeKitsune]

When should the next update come out? And will starts work? Also, how do rings work?

Edited February 8, 2015 by TheJewelOfJool

[sdj64]

I *think* that I have fixed all of the problems I have been having. I only have to clean up the enormous mess I've made of my files trying to get them to work. I'll post some screenshots of my planets soon (maybe a dev thread) and a little while after that, a tutorial on how to make atmospheres and use heightmaps properly with Kittopia.

[Borisbee]

Ok I think I found a bug and has potential to cause some trouble. Seems sometimes duplicate PQS systems are not accounted for in the config when loading. I used the Mun as a template, and I wanted to disable all the PQS cities and flattens, but keep both VoronoiCraters mods. I'm able to change and save the first mod, but the second one gets saved out but when loaded back, only the first mod is accounted for. This can be tested by using the Mun as a template. Save the config and then go and change the mod to disabled in the config and reload it in Kittopia. You will see the first Crater mod will follow the rules the config set, but the second one is ignored.

[Lillz]

So the T-K planet pack has exported scaled space files (the .bin files) but NOT exported scaled space textures.... why?

[Gravitasi]

So, it seems to by the case that unless you use Mun as your template body, attempting to use VoronoiCraters makes the planet disappear. I'm sure this is because Mun is the only body to use craters so naturally it works there, but I'm wondering if someone with more knowledge on the PQS system could tell me a theory on why it doesn't work when trying to apply to a different body. Frustrating to not be able to use them on bodies since they are great for adding little detail to what might be an otherwise boring surface.

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.

Ok I think I found a bug and has potential to cause some trouble. Seems sometimes duplicate PQS systems are not accounted for in the config when loading. I used the Mun as a template, and I wanted to disable all the PQS cities and flattens, but keep both VoronoiCraters mods. I'm able to change and save the first mod, but the second one gets saved out but when loaded back, only the first mod is accounted for. This can be tested by using the Mun as a template. Save the config and then go and change the mod to disabled in the config and reload it in Kittopia. You will see the first Crater mod will follow the rules the config set, but the second one is ignored.

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.

So the T-K planet pack has exported scaled space files (the .bin files) but NOT exported scaled space textures.... why?

They were exported; but I deleted/moved the scaled space textures after the exporting process. Maybe this post could give you more information.

[Proot]

Hi, (my apologies if this has been asked before) I use KittopiaTech to create rings in Jool and some other effects for the stock game. So, once discontinued KittopiaTech, may I use this to do the same or this is dependant on the updates of KittopiaTech too? can be the settings used directly here or need I some type of re-making? Thanks!

[Tellion]

Now first, thank you very much Gravitasi for taking on this project, the work you do is absolutely magnificent!

I just started playing around with the various tools for creating and editing planets and am far from making anything remotely acceptable, but I have discovered a few issues in the meanwhile. I am not sure which of those, if any, are in your power to fix, but I figured asking wont hurt.

The first one concerns the sun shining through planets, especially ones that are significantly larger than their templates. This will concern everyone trying to make realistically sized planetary systems, and is especially noticeable on gas giants.

The second one is about Kittopia's sphereOfinfluence parameter, it seems like this one does not get applied at game load; however it does get applied when loading manually from the ingame gui. This one is important for everyone striving to make asteroids and small bodies without neutron star densities, KSP's way of calculating SOI's offers no other ways around that in many instances.

The third one... you apparently resolved before I had the chance to report here, I fail to recreate it. That one was about planets much larger than their templates disappearing when looked at from an angle. I am blown away, you cannot believe how much that bugged me

Whatever you did to fix that, thank you!

Here is a small imgur album demonstrating 1) and 2)

[Lillz]

They were exported; but I deleted/moved the scaled space textures after the exporting process. Maybe this post could give you more information.

Ahh I see. Is there any way for the scaled space textures to be exported at a higher resolution than 2048x1024?

[KCreator]

Hi, (my apologies if this has been asked before) I use KittopiaTech to create rings in Jool and some other effects for the stock game. So, once discontinued KittopiaTech, may I use this to do the same or this is dependant on the updates of KittopiaTech too? can be the settings used directly here or need I some type of re-making? Thanks!

This plugin is KittopiaTechs first continuation, as far as I am aware. So as long as Gravitasi doesn't change how the config parser asks the plugin to make rings, your existing configuration should work fine. Simply ask people to download this instead of my discontinued work, as this will likely be updated to any future KSP version.

[CaptRobau]

I just noticed the biome fixing update. Will try out now!

[VonFrank]

Something desperately needed IMO is the ability to set a LAN (longitude of ascending node) value to rings.

The way rings work currently is alright if you want them to have no inclination whatsoever (take Sarnus and Urlum from the Outer Planets Mod for example), but if you want to have the rings on your planet inclined, things get a little bit more complicated. For example, trying to recreate Saturn with its ring inclination of approx 27 degrees means you need to lock the ring rotation, otherwise the rotation of the rings will wobble around with the rotation of the planet because of KSP's lack of an axial tilt system, which is, of course, unrealistic. However, while locking the ring rotation solves the problem of the silly looking ring wobble, it means that the rings are stuck at an arbitrary position that might not line up with the LAN angle of the planet's moons.

See the following screenshots for an explanation of the problem:

As you can see, an accurate representation of Uranus suffers from the same problem.

What I suggest, is the ability to specify a specific Longitude of Ascending Node for the rings of a planet. This will make it possible to match the LAN value of the rings to the approximate LAN values of the planet's moons in order to line them up properly and ensure they are always lined up no matter what.

What do you guys think about this? Is this even possible? If not, is there a way to get around the issue?