R-T-B

The one on github has been zipped with some third-party utility windows doesn't understand. Something like winrar or 7zip can open it. Or you can grab it from one of the other hosts and it should open as he used a more normal zip there.

That's right, no sooner than I started planning it, I did it. Big feature and bugfix release is here! Please try out the new config options and see how they work! They are explained above (and a bit below too.) Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 14 R-T-B released this 18 seconds ago 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. This is release 14. It contains the following changes: 1.) Added a config file (GameData\Kopernicus\Config\Kopernicus_Config.cfg) that enables you to turn on/off various options. Look inside! You can turn off warnings and more! Plus if your a planet pack author constructing a completely new system, you probably want to shut off the stockAsteroidGenerator, which is on by default now for Comet support and SENTINEL Contracts. 2.) Fixed a bug with the rimshader by using some mystical property of eeloo this is not fully understood in the templating process. This seems to work well, but may introduce new bugs, so I'm curious how it performs! 3.) In the default stock system, we can spawn comets now using Squads system, though it is untested. It should work though, try it! Known Bugs: 1.) Right now? Nothing big! Famous last words? Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc. Thanks and as always, report bugs! -RTB

Nevermind, the issue is we shut off the stock asteroid generator by default. That's not ideal, and about to change. Next release will fix that bug. On that note: Next release has important config options in a file called Kopernicus_Config.cfg! It is found in the usual config folder, and an example version is listed below (not used yet, will probably be implemented on bleeding edge soon). Feel free to use it as both a planet pack author and a user to change stock behavior! The following options are available: // Kopernicus base configuration. Provides ability to flag things and set user options. Ships at defaults for stock system and warnings config, as well as an explanation that is not part of the file: Kopernicus_config { EnforceShaders = true WarnShaders = true UseStockAsteroidGenerator = true } EXPLANATION: They are pretty self explanatory. But enforceShaders forces shaders to Ultra, and can be disabled. WarnShaders produces a warning if shaders are not on Ultra, and can be disabled. UseStockAsteroidGenerator allows the stock asteroid system to run alongside Kopernicus's, and in the future will be on unless planet pack authors or users toggle it off for their pack of choice. This enables spawning of asteroids in and around Kerbin/Dres as well as random asteorids for SENTINEL contracts. Some packs may not want this, so it can be turned off.

Hmm. What I really need is to determine if this happened in the last release. Could you just test one release back? And then post log files if it still happens? Thanks. I'm wondering if disabling the Sentinel contracts because they were unfullfillable actually killed off the asteroids too. That would be bad. If so, rolling back should fix it.

Yeah, I suspect asteroids have been acting up in 1.10.1 (not sure, but have had one or two reports). Is that what you were testing on? That's not a CKAN blocker issue but we do need to deal with it. It's probably something related to comets that they changed, if I had to guess. If I get more reports of them not spawning I'll definitely mark it an issue for a true 1.10.1 release (right now it's sort of hard to rule out mods on all the reports I've gotten). I'm 99% sure they are working on in 1.9.1 right now though. I also would like to reduce the logspam. Kopernicus likes to log a lot of little warnings right now that don't really matter one iota in 99% of situations, like on bleeding edge it complains about textures that are missing that no one cares about (because we don't enforce ultra-shaders in BE). I'd like to quiet it a bit someday, but that's a "stretch goal."

Yep. That's the plan. There is still at least one bug I consider a blocker to CKAN on stable, but it'll be dead soon. We are probably closer than we've ever been, but I'm not going to give estimates this time because they come back and bite me. Just stick with stable releases on CKAN and you'll always be ok. We will ensure the updating is painless, too.

@Vabien More important than the above, Kopernicus is looking at baking comets into our custom asteroid system. Would the old CometTails code found in Kopernicus Expansion be helpful here? I know it requires particles, but my bleeding edge branch has had those working for some time, if you want to try to get it running. We may even bake it into Kopernicus itself (ideally to allow a configurable comet system) pending review. Basically, we could use help updating the shaders, which I think we need to do. Other than that, I'm sure I can handle it.

On that note, little baby bugfix to avoid utterly undoable SENTINEL missions (I just forced them not to be generated). Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 13 R-T-B released this now 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. This is release 13. It contains the following changes: 1.) Fixed a bug where SENTINEL missions were being assigned despite being unfulfillable (we bake our own asteroid system, it doesn't work with SENTINEL missions) Known Bugs: 1.) Right now? Nothing big! Famous last words? 2.) As of now, the 1.10.1 releases do not support comets. We are planning support soon, PRs welcome if you can help. Yes, this possibly means comet missions may be unfullfillable too, if you get such missions don't take them (they shouldn't, but who knows? Report if you get them.) Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc. Thanks and as always, report bugs! -RTB This will probably be the last BE release until comet support, barring major bugs being discovered. Also, if this proves to be reliable code, it has a good chance of being the CKAN candidate upstream in Prestja's branch.

We actually discussed this internally and came up with a better answer I think: Stock comets won't be implemented (and thus we can keep custom asteroids), because we already have our own custom comets. KopernicusExpansion has code for comets that only requires particles, which I've already added. I'll see about updating it and integrating it into mainline Kopernicus.

I take that silence as a good thing. I'd like to highlight this: 3.) As of now, the 1.10.1 releases do not support comets. I'd welcome PR's to fix that, because I have no idea where to start. To clarify what the issue is here... Kopernicus at present takes complete control of stock asteroids (and thus comets) at the moment, including their generation. This allows users to create custom belts, etc, with size distribution and other fun stuff. It's also causing us a heck of a lot of problems in regards to enabling comets. Would users mind if I disabled this and just let the squad asteroid system run in it's place? I'm seeking feedback from both planet pack authors and users, here. It'd fix the problem, but we'd lose this functionality, and it'd just act like stock always in regards to how they spawned (around Kerbin/dres space really).

About where I was with that, lol. Kids who desire a flat KSP can always play minecraft with some unlimited zheight mod. I like my space marbles.

Weird. Wonder what I did wrong. I'll look at my configs again. To be clear, I am getting footprints on Kerbin, despite setting allowFootprints = false in a dedicated config.

Hey @Vabien, it seems for me I am unable to actually uh, disable the footprints on any given body. Is anyone else experiencing this?

It's a kopernicus and/or stock bug, been there since 1.8 aparently. We are tracking it but have no idea what causes it. I'll find the bug link on our tracker, just a second. https://github.com/prestja/Kopernicus/issues/26

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 12 R-T-B released this now 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. This is release 12. It contains the following changes: 1.) The return of multistar support! This support is well tested in many environments by me personally and should behave similarly (though not identically, it's more scientific!) to stock, but bug reports of significant deviations from what is expected are appreciated (keep in mind stock does not support multistar!) 2.) Also added/Implemented atmospheric extinction to the multistar EC calc. This means atmosphere now can reduce solar output, just like in stock. (Temperature too, something I didn't even know happened until NathanKell explained it to me!) 3.) Fixed the 1.10.1 menu freeze bug. 4.) Updated Module Manager to 4.1.4. Known Bugs: 1.) Right now? None! Famous last words? 2.) You may have an issue where in flight flights are not using the new panel math. If so, this is not fixable, you will simply have to start a new flight. I hope this is not the case, but it could be. 3.) As of now, the 1.10.1 releases do not support comets. I'd welcome PR's to fix that, because I have no idea where to start. Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc. Thanks and as always, report bugs! -RTB

Heads up for the next build! We will be reimplementing multistar support in the next build. It will work, as tested by my team, and not generate crazy ECs, but there are some caveats I want to emphasize below: 1.) It has to "hijack" the stock panels in a new way. This means you may not get the full affect of the new fixes until a new flight is launched. Present flights behaviors may be strange or off in regards to EC (unsure really, this is a maybe, they should be fine but it could happen). 2.) We are unsure if mods that rely on disabling the Kopernicus panels will understand this. Testing wanted. It will be out soon. You can always stay a build behind if you don't want to be a tester here.

I actually have fixed the bug and it wasn't to do with input locking, but indeed removing elements it shouldn't have been removing (PQS remover run amok). It's already fixed at the repo and will be in next release. We're just working on something kind of big to test on the side here to go along with it, it should be out soon.

No, we encourage their use with a warning that you may get an inconsistent look, but we have opted not to force the user to them in bleeding edge builds. Whether or not that makes it to stable depends on a few things... but right now it's looking positive. Regardless, these releases warn, but do not force. Ooh. Maybe it's an input lock issue rather than a PQS issue? That would certainly make more sense. Yes, it's a clue. No idea what it means yet but it is certainly something important... heh. I do apologize that the 1.10.1 input issue is being so slow to fix. The cause has thus far proved pretty ellusive. Frustrating.

You've enabled a major breakthrough on our multistar efforts today in Kopernicus. The answer was as simple as you stated. It's amazing sometimes how we can't see the simplest of solutions in our own code. Many thanks. The commits are already on my tree, and entering testing with my crew now.

Sounds pretty promising thus far. I'm encouraged that that bug is fixed for now at least. The only issue with the fix is forward facing, in 1.10.1 it seems they made the main menu's "hitboxes" a PQS of the menu planet (why? Why?). Yes, this means the main menu doesn't work without arrow keys in 1.10.1 going forward. We'll deal with that in the bleeding edge though. I'm sure we can whitelist the main menu somehow.

That might work. Thanks for the idea! I'll try it soon here... would be nice to get another stab at multistar out but first I've got to do *sighs* real life work... lol. Thanks for getting back to me, I was stumped and didn't know what part was making the ECs. If it's just PostCaclulateTracking, I think we can work around this.

I'd advise the same. And yeah, KopernicusExpansion only works in a limited sense in 1.9+, see this for the working bits; If after further testing it is indeed affecting in game clickable menus, I'll add a bug report, of course. It's probably stemming from the same issue either way, but I hope it's not that widespread.

My branch fixes this. https://github.com/R-T-B/EnvironmentalVisualEnhancements I really didn't want it to come to this, but... This mod is quintessential to the KSP ecosystem, and is aparently abandoned other than @BIOZ's latest work. I assume your work is open domain, @BIOZ? If so, I will be integrating it into my tree and excercising a community takeover of eve, since my build has been the only one working right (right being mostly bugfree) for quite some time. I can open a new thread if desirable. There'll be a proper 1.10.x release today. @BIOZ, I can add you as a github contributor if you'd like, given you are obviously capable (and I'm overtaxed with Kopernicus as is). Anyways, until I have time to make a thread, get releases here: https://github.com/R-T-B/EnvironmentalVisualEnhancements/releases There'll be a true 1.10.1 ready one in a few minutes. (with @BIOZ's fixes, if he objects I will take down). I also integrated the cloud fixes mentioned above that i've had fixed for months now. PS: This project is a lower priority on my totem pole than Kopernicus, and as such, I'd really like someone to consider adopting it other than me. I'm just doing what must be done for now.

I believe the last stable release on this branch may have fixed the issue with PQScities (monoliths, random discoverable things) "sticking" to the body from which they were templated. If anyone would care to confirm in a game test, that'd be great, though. That would move us basically to CKAN status, pending one more bugfix I think I can get done today. You are probably going to ask how to test. The easiest way I think would be to look for the "Mohole" on a body templated from Moho. It shouldn't be there. I'd do this myself, but ironically, despite being a bigtime Kopernicus dev now, I don't want to teleport to Moho or a body templated off of it as i haven't actually MADE it to Moho in my game yet. Yeah yeah, I know.

Yeah, that's what I'm finding today. The code is in fact rerunning and removing the PQS that is the main menu, again. Which is what it should do, but it doesn't help us right here and now. We need to tell it to leave the main menu alone, lol. Whoever at squad thought the main menu should be a PQS is sorta... I mean if they were going to do that, why not from day 1? Why wait for 1.10.1? Sometimes their choices confound me. But I'm working on it.