Jump to content

[1.9.1-1.11]R-T-B's Kopernicus Unified "Bleeding Edge" Branch


Recommended Posts

Kopernicus Continued Planetary System Modifier is a mod that provides for the graceful introduction of new celestial bodies to Kerbal Space Program.  This is where we test new things and learn how break the universe with gusto.

Disclaimer

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.  These features do get tested, briefly, and they generally work, but still, bugs can be slip by and be real, so it is important to BACK UP YOUR SAVEGAMES!

It should be noted I am a member of the current Kopernicus Maintainence effort and this is an official Kopernicus-Continued subproject.

Features:

Presently, over the base Prestja Kopernicus-Continued branch, this branch also features.

 

1.)  A common source code base for both 1.9.1-1.11, enabling easy retrocompatability when we fully move to 1.10.x.  Yes, this means we can support old releases well into the future if this works.

versionlock807.png

2.)  Cool stuff you have no idea... (do I even?) 

untitled.png

3.)  bugs???

eastern-boxelder-bug.jpg

FAQ:

1.) When will this leave development?

A.)  It won't.  The whole idea is this is the eternal testing ground.  It stays here forever and ever and ever...

2.)  What does this mod do?

A.)  On it's own, nothing.  It's generally a dependency or modders tool.

3.)  Can I has a CKAN version?

A.)  Sure, just opt in to our private beta CKAN repo.  This will grant you auto updates from the beta tree and get you all this stuff straight from CKAN!  Do the following technique to start this:

From your main CKAN window, go to "Settings"

Add our CKAN repo in the resulting text box.  It's the one called "Kopernicus_BE"

No more FAQ for now, ask me something frequently and I may add it to stop you...

Downloads

Kopernicus "Bleeding Edge" Unified Downloads  (the base mod)

KittopiaTech "Bleeding Edge" Unified Downloads  (this is basically a GUI for Kopernicus pack developers, hit CTRL-P in mapview, most don't need it)

Please ensure you grab the right version for your KSP version!  1.9.1 needs a zip with _191_ in the filename, 1.10 needs _110_, 1.10.1 is _1101_, etc.

Credit

Credit must be given to other current Kopernicus Maintainers @prestja, as well as previous authors @Thomas P. , @Sigma88  and many others for their incredible work in building an elegant solution for bringing new worlds to KSP.

Source Code

Source code can be found on the GitHub repository.                                   

See branch dev1101 for details.

License

Kopernicus is licensed under the GNU Lesser General Public License

Edited by R-T-B
Link to post
Share on other sites

@R-T-B, if you want something to put on your todo list, here's an idea that I'm sure would be very welcomed by the planet modding community...  allow the placement of terrain scatters by biome.

At present terrain scatters are placed using LandControl, in which landClasses are created for the placement of specific types of scatters.  LandClasses are defined by latitude, longtitude and altitude ranges.  While it would be good to keep those ranges, an additional biome parameter would be awesome.  I've seen many inquiries about this, so I'm sure modders would be thrilled to have that optional available.

Link to post
Share on other sites

I can look into it.  That is a great idea...  I'm still learning the Kopernicus code in some ways (it's quite the beast!), but I'll definitely look into the feasability of that.  Right after we make an interface for Jool's new shader system and document it... (working on this now).

 

And yeah, I welcome suggestions like this as long as they fit the scope of Kopernicus.  Pull requests are great too, but I understand not everyone is a coder.

Edited by R-T-B
Link to post
Share on other sites

@R-T-B, while you're looking into it, there's also a bug in the longitude range when placing scatters.  @Sigma88 struggled with it and said he thought it was a stock bug, so maybe there's nothing that can be done about it.  Perhaps he can explain more about it.  But if it can be fixed, it would be welcomed.  Here's the bug, as I remember it...

The longitude range is from 0 to 1, with 0 being the left edge of the texture maps, and 1 being the right edge of the texture maps.  When we use the entire range of longitude (0 to 1), scatters place OK.  But when we limit the range to some less than the full range of longitude, nothing places in the fourth quadrant of the map, i.e. from 0.75 to 1.  For example, let's say I define a land class that has a longitude range of 0.6 to 0.9.  Scatters will place OK between 0.6 and 0.75, but no scatters will place between 0.75 and 0.9.

Link to post
Share on other sites
2 hours ago, OhioBob said:

@R-T-B, while you're looking into it, there's also a bug in the longitude range when placing scatters.  @Sigma88 struggled with it and said he thought it was a stock bug, so maybe there's nothing that can be done about it.  Perhaps he can explain more about it.  But if it can be fixed, it would be welcomed.  Here's the bug, as I remember it...

The longitude range is from 0 to 1, with 0 being the left edge of the texture maps, and 1 being the right edge of the texture maps.  When we use the entire range of longitude (0 to 1), scatters place OK.  But when we limit the range to some less than the full range of longitude, nothing places in the fourth quadrant of the map, i.e. from 0.75 to 1.  For example, let's say I define a land class that has a longitude range of 0.6 to 0.9.  Scatters will place OK between 0.6 and 0.75, but no scatters will place between 0.75 and 0.9.

Ok, I think I'll probably try to fix that in the same sweep.  It'll be a good invesigative course for when I get done with the gas giant shader interface (that'll likely take a day or two).

EDIT:  Actually, I think I may have a lead on this particular bug, it looks like it may be something we can deal with in the Utilities class.  maybe.  But your description isn't quite adding up. I found a land control example in JNSQ, and it uses way more range than 0 to 1...  we've got longitudes of 2, and -1....  can you help elaborate how it is supposed to work given this example of the iceberg fields from there?  Maybe you mean the bug is for latitude?  Maybe someone with knowledge of this bug could test if it still exists and/or elaborate?

We did change some scatter code and fix some scatter bugs, it's possible it may already be fixed.

Example LandControl entry you can use for your explanations to me as to the workings of this system, if you volunteer:

Quote

Class
                        {
                            name = OceanIcebergs
                            alterApparentHeight = 0
                            alterRealHeight = 0
                            color = 1,0.5,0,1
                            coverageBlend = 0
                            coverageFrequency = 1
                            coverageOctaves = 1
                            coveragePersistance = 1
                            coverageSeed = 12345
                            latDelta = 1
                            latitudeDouble = True
                            lonDelta = 1
                            minimumRealHeight = 0
                            noiseBlend = 0
                            noiseColor = 0,0,0,0
                            noiseFrequency = 1
                            noiseOctaves = 1
                            noisePersistance = 1
                            noiseSeed = 54321
                            delete = False
                            altitudeRange
                            {
                                endEnd = 0.05
                                endStart = 0.05
                                startEnd = -1
                                startStart = -1
                            }
                            latitudeRange
                            {
                                endEnd = 0.2
                                endStart = 0.15
                                startEnd = 0.1
                                startStart = 0.05
                            }
                            latitudeDoubleRange
                            {
                                endEnd = 0.95
                                endStart = 0.9
                                startEnd = 0.85
                                startStart = 0.8
                            }
                            longitudeRange
                            {
                                endEnd = 2
                                endStart = 2
                                startEnd = -1
                                startStart = -1
                            }
                            scatters
                            {
                                Scatter
                                {
                                    density = 0.35
                                    scatterName = iceberg
                                }
                            }
                        }

Edited by R-T-B
Link to post
Share on other sites
22 hours ago, R-T-B said:

EDIT:  Actually, I think I may have a lead on this particular bug, it looks like it may be something we can deal with in the Utilities class.  maybe.  But your description isn't quite adding up. I found a land control example in JNSQ, and it uses way more range than 0 to 1...  we've got longitudes of 2, and -1....  can you help elaborate how it is supposed to work given this example of the iceberg fields from there?  Maybe you mean the bug is for latitude?  Maybe someone with knowledge of this bug could test if it still exists and/or elaborate?

We did change some scatter code and fix some scatter bugs, it's possible it may already be fixed.

Example LandControl entry you can use for your explanations to me as to the workings of this system, if you volunteer:

Using -1 to 2 is just to provide some overlap to assure there aren't any seams.  -1 to 2 is effectively the same as 0 to 1.  (Same thing with starting altitudeRange at -1 instead of 0.)  When the full range of longitude is used like that, the bug doesn't occur.  For instance, you'll find icebergs at all longitudes all the way around the planet.  If you want an example from JNSQ that produces the bug, look at the Desert land class.

Spoiler

                        Class
                        {
                            name = Desert
                            alterApparentHeight = 0
                            alterRealHeight = 0
                            color = 1,0,0,1
                            coverageBlend = 0
                            coverageFrequency = 1
                            coverageOctaves = 1
                            coveragePersistance = 1
                            coverageSeed = 12345
                            latDelta = 1
                            latitudeDouble = False
                            lonDelta = 1
                            minimumRealHeight = 0
                            noiseBlend = 0
                            noiseColor = 0,0,0,0
                            noiseFrequency = 1
                            noiseOctaves = 1
                            noisePersistance = 1
                            noiseSeed = 54321
                            delete = False
                            altitudeRange
                            {
                                endEnd = 0.68
                                endStart = 0.64
                                startEnd = 0.21
                                startStart = 0.19
                            }
                            latitudeRange
                            {
                                endEnd = 0.61
                                endStart = 0.59
                                startEnd = 0.41
                                startStart = 0.39
                            }
                            longitudeRange
                            {
                                endEnd = 1
                                endStart = 0.99
                                startEnd = 0.61
                                startStart = 0.59
                            }
                            scatters
                            {
                                Scatter
                                {
                                    density = 1
                                    scatterName = cactus
                                }
                            }
                        }

Here longitudeRange starts at 0.59 and ends at 1.  If you were to explore this area, you'd see cacti from longitudes of 0.59 to 0.75 (122.4 W to 180 W), but then they abruptly stop and there are none from 0.75 to 1 (180 E to 90 E).  At least that's the way it was when I last tested it, which was probably a year ago.  I haven't tested it recently, but based on my conversations with Sigma88, I doubt anything has changed.  Sigma indicated to me that he observed the same bug and wasn't able to fix it.

(Edit)

I just tested it in KSP 1.9.1 and the bug definitely still exists.  In the image below we're looking due north along the 180-degree line of longitude (0.75).  I've turned on createColors to show the land classes, and I increased the scatter density.  The pink is the Desert land class.  According to the settings in the config, the Desert land class should extend from longitude 0.59 to 1, so the pink should extend all the way across the screenshot.  But we can see that it ends at 0.75.  We can also see many cacti to the right in the pink area (<0.75 longitude).  There are a few cacti to the left, but that's probably just due to randomness in their placement (they disappear completely as we move farther to the left).

Spoiler

DwWfYVf.jpg

 

Edited by OhioBob
Link to post
Share on other sites
16 hours ago, R-T-B said:

Maybe you mean the bug is for latitude?

Yes, it is latitude. Or maybe both.
I’ve struggled with this bug myself in my Terrainium project. I have also encountered similar  issues when trying to specify a very narrow range (equivalent to <1 degree). My goal was to locate scatter-based cities, but the limits in gamenever really matched the inputs.

A major usability improvement would be to   allow input of Latitude (-90 - +90) and longitude (-180 - +180) In degrees rather than percents, although the calculation is not too hard, it is still a barrier to entry and complicates things.

...

I have seen some configs using ranges beyond 0-1 for these values but never knew why. Maybe the intention was to “triple wrap” the area.

Link to post
Share on other sites

So, I hope you don't mind me asking, but I'm really inexperienced with the technical properties of Kopernicus, and I am planning on using Kopernicus for my new mission report, once Kopernicus is stable for 1.10. I'm waiting until it has too few bugs to matter for Outer Planets Mod, but I haven't been able to easily understand the current bugs for previously mentioned reasons, but I still need to figure out if any bugs matter enough for me to postpone Kopernicus.

Which brings me to the topic of this post.

Might I know the current unsolved bugs (preferrably in layman's terms so I can understand them better than the wordings provided previously), so I may decide whether to use Kopernicus now or wait until it is more stable?

Link to post
Share on other sites
1 hour ago, LittleBitMore said:

Might I know the current unsolved bugs (preferrably in layman's terms so I can understand them better than the wordings provided previously), so I may decide whether to use Kopernicus now or wait until it is more stable?

No issue in asking!  This isn't just dev talk but user talk as well. :)

You can find all known open/unresolved bugs on my github page.  There aren't many right now really, just feature requests mostly:

https://github.com/R-T-B/Kopernicus/issues

Resolved (fixed now) bugs are listed in closed tab.

https://github.com/R-T-B/Kopernicus/issues?q=is%3Aissue+is%3Aclosed

For the record, I am presently playing on 1.10, so I "eat my own dogfood" at the moment, and have not noticed any big bugs.

Also, thanks @OhioBob, I think I know where to look now.  It may indeed be a stock issue, but I hope we can at least work around it in code.

2 hours ago, Nightside said:

A major usability improvement would be to   allow input of Latitude (-90 - +90) and longitude (-180 - +180) In degrees rather than percents, although the calculation is not too hard, it is still a barrier to entry and complicates things.

This would be good but we'd have to retain backwards comparability, so it'd have to be a new parameter name or something.

Edited by R-T-B
Link to post
Share on other sites
7 minutes ago, R-T-B said:

For the record, I am presently playing on 1.10, so I "eat my own dogfood" at the moment, and have not noticed any big bugs.

So, just to be sure, playing in OPM with this version of Kopernicus should do nothing super wrong?

Link to post
Share on other sites
6 minutes ago, LittleBitMore said:

So, just to be sure, playing in OPM with this version of Kopernicus should do nothing super wrong?

I mean, 99% certain it should be fine.  I've yet to say, visit all the gas giants and planets personally without cheating, but yeah, it seems to work.  Nothing "super wrong" certainly.  I've even tested OPM.

I really just tell people to back up their saves because they should anyways.  Game breaking bugs are rare but I don't want to be "that guy" if the apocalypse happens, you should always backup.

I play with JNSQ on 1.10, which actually is a little more heavy than OPM.  It works.  Even icebergs and their colliders work, which was a cool surprise. :)

screenshot10.jpg

Edited by R-T-B
Link to post
Share on other sites
1 minute ago, LittleBitMore said:

Nice-- thank you very much, I'll get my OPM mission report started up.

Once I finish this Scott Manley video.

Appreciate it, I'll watch for it and wish you the best mission results!

If you do find any bugs, they'll most likely be minor and/or visual-only, but do report them.  I haven't heard a report in a bit but every little bit helps.

Edited by R-T-B
Link to post
Share on other sites
Just now, R-T-B said:

Appreciate it, I'll watch for it and wish you the best mission results!

Thank you! It's actually already up, just not officially begun because I was afraid to try out Kopernicus before some confirmation it would work well. It still needs a few other things done, like the modlist and deciding whether to do science or career, but I have a few interesting twists I plan to apply to my mission report. There is a link in my signature if you want to visit it.

right, but I won't venture too far off topic if you don't want me to. I'll tell you if anything goes wrong with Kopernicus in my mission report.

Link to post
Share on other sites
Just now, LittleBitMore said:

right, but I won't venture too far off topic if you don't want me to. I'll tell you if anything goes wrong with Kopernicus in my mission report.

Sounds like a good plan.

Link to post
Share on other sites
Link to post
Share on other sites
Just now, pmborg said:

Technically I support 1.9.1 as well, with extra features like particles.  But my branch is more experimental than Prestja's, he is more "slow and steady" reliable where I'm more "let's get this thing updated immediately," hence the divergent versions.

A lot of my fixes end up in Prestja's stuff though after testing.  I do advise planet pack authors to test on Prestja's branch for 1.9.1, and mine for 1.10 (since it's the only one).

Link to post
Share on other sites

New release of my branch, release 2.  It's just a small bugfix release to keep us in bugfix parity with Prestja's work.  It includes a bugfix for atmospheric temp calculations in multistar planet packs (they were referencing the wrong star).

Get it in releases above, or here:

https://github.com/R-T-B/Kopernicus/releases/tag/UBE-release-2

EDIT:  This one has bugs, hold off.

Edited by R-T-B
Link to post
Share on other sites

Hold off on downloading release 2, it has a bug that was also in Prestja's branch.  It's not a MAJOR bug but it does make atmospheric temps a bit lower than they should be, and takes away their variance.  I am scrubbing it out and making a new release now.

New release of my branch, release 3.  It's just a small bugfix of the last bugfix (lol don't you love that) that actually made things worse.

Please test and advise.  This one should be harmless (not that any of them are "save game eating" bugs but they did have some wrong math on temps).

https://github.com/R-T-B/Kopernicus/releases/tag/UBE-release-3

Edited by R-T-B
Link to post
Share on other sites
1 minute ago, OhioBob said:

@R-T-B, I just tested GEP with release 3 and the temperatures are now working correctly.

Yeah, it was pretty much just a dumb mistake on my part by working too fast.  Will try not to let it happen again by working at home in the future and not at work, lol.

Thanks for the report.  I'll probably push it to stable by tomorrow.

Edited by R-T-B
Link to post
Share on other sites

There was a small bug with the above fix afterall...  it does not work on moons with atmospheres (poor laythe).  We still had bad, colder and more uniform temp calculations on them.  No good, and the origin was pretty simple but just required me to chill out for a bit so my brain could work.  Unfortunately, it's too late to run it through proper Q&A though.

It will be ready sometime tomorrow.  Need more brain sleep.

Edited by R-T-B
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...