R-T-B

Thanks, will investigate. EDIT: It's the new PQS fixes I attempted, to remove randoliths and the like. Is it maybe depending on a templated discoverable thing from the host body that is being now scrubbed? If so that's not proper behavior. Can I see the config of body Alva? If you don't know where to find that, a link to "Galaxies Unbound" should do. Nevermind, found it myself. Looking at it.

lol, you and me had to overcome the same block I think.

Honestly, I'd just make a separate game and teleport. Not career mode, something like sandbox (sinful thing that it is).

Vabien is taking to this coding stuff like a fish to water. He's living up to his title on this forum. His art skills coupled with budding coding skills will make him perfect for maintaining this.

This is why I learned to use the cheat menu to teleport like nuts. Takes some of the mystery of discovery out of the game though, so don't blame you. Don't feel obligated, I have a swarm of testers that come on in the evening like locusts, I swear. Good, helpful locusts.

We've really been holding ourselves to a high standard for that, so yeah. When it gets there it'll be trustworthy for sure. We possess control of the original CKAN repo that Kopernicus uses, so the release process will be integrated natively and simple. To be clear though, I'm a code monkey (/frog). @prestja calls the shots by virtue of being a better project manager, so it's up to him when the lever gets pulled.

Final bit of post spam here, relating to the status of CKAN support, which I know many of you have been waiting for. CKAN is nearly here. I know, I've been saying that for a while, but really, it is. We're at the point where we are fixing old 1.8 bugs and such more often than new ones, frankly. I'd say the builds in the stable tree at this point are actually more stable and fucntional than the last 1.8.1 release, which was perfectly usable as it stood. So if you've been waiting to download, we are pretty much there, go ahead. Still, CKAN is considered our gold standard, hence the delay, but we are down to only one relatively minor issue blocking it's release! Hopefully, provided no others crop up, that'll be knocked out in the next few days (you can help by testing bleeding edge, it already has a test fix). Then, following a testing period of a day or so, we'll probably drop it to the CKAN network. You can keep abreast as to CKAN's status here: https://github.com/prestja/Kopernicus/issues/29 Thanks for reading, even if you just skimmed the bold bits! The issue above is also a great way to know a summary of the stable branch's big issues, btw.

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 8 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 8. It contains the following changes: 1.) A bugfix to the internal EC calc. Though EC calculations were displayed correctly, charge rate was wrong and drifted exponentially the farther you got from home orbit. 2.) The multistar calc has been made luminosity aware, so if one changes the luminosity of the home star, the math doesn't fail to behave as expected. 3.) An exmperimental fix for PQSCitys (like randoliths) sticking to templates when unwanted (needs testing). 4.) Even better tested 1.10.1 support. 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 I added bold to the above because I'd really like that tested. It may or may not work, but if it does, stable could really use it. @Vabien, @etmoonshade

Kopernicus 1.9.1-8 R-T-B released this now This release fixes a few multistar panel tracking bugs. In the previous release, the displayed math was right, but internally, it was incorrectly calculated. Also, this release is now aware of the home stars luminosity and can do calculations based off of it, in cases it changes from the stock 1360. You can now use multistar packs without hesitation, even ones that change the main star. This has been well-tested in the bleeding edge branch before being used here. Download with confidence.

The biggest known glitch right now is the last dev push had a glitch which has charge rate either way higher, or way lower than reported, depending on how far from Kerbin you are it may or may not be an issue. It's most noticable at far or near solar orbits. Anyhow, it's being fixed now. A hotfix will be out for stable and my bleeding edge in a few minutes here, we are just doing final tests. EDIT: Hotfix is done, please see below. It will drop also in public bleeding edge in a few seconds.

Really? Oof. I will investigate. I wonder what's really going on under the hood there... no other mods, right? Can anyone else replicate? This bug is probably in stable too if it's genuine, but if it is, we'll have it fixed today if at all possible. EDIT: Bug found and fixed codeside. Will compile and fix when I get home... eta 1 hour.

The moons? That's what we were discussing.

Release 7, fixing nearly all (if not all) multistar panel EC issues is out. Major shoutout to @OhioBob for help with the math, and my team of testers at Kopernicus Bleeding edge for helping me test the code. The bleeding edge also has these same fixes, obviously. Download in OP or here: https://github.com/prestja/Kopernicus/releases

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 7 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 7. It contains the following changes: 1.) Rolled back the locked starlight limiting EC math in Release 6 2.) Added a new, complete multistar support math system that works perfectly. The only thing it doesn't allow for is absolute/relative exposure display. Those options have been removed, and now exposure only shows the tracked star, but overall light-to-panel comes from all stars, as it should. 3.) Slightly better tested 1.10.1 support. 4.) Drop support for 1.10. 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 Yep, that's right. We fixed multistar-panel support. Major thanks to @OhioBob for the math help. Pull requests welcome if you figure it out, that's the only real major bug I got left before I start finally going back to those Jool shaders.

This is why KopEx needed artists more than it needed coders, lol. Shoot any code questions you may have my way though and I'll be happy to help.

I thought atlas just outright broke them, seems I was wrong lol.

That would be interesting to know.

Thank you for confirming it is Joolian moon-templates that seem to do this worst. I'm unsure why. The only thing I can think of is that maybe they feature the atlas shader and others do not? (Laythe got atlas in 1.10, maybe others).

That's a really good question. Technically, they are in a seperate "if" branch, so I didn't alter their code at all. If they are functioning right though, one would very much wonder how, and maybe we could glean something from them. Or if they are broken, I should probably fix that. Either way, very good question that I am going to test out right now.

I keep telling myself that but am also in discussions with @OhioBob about the math, so maybe we can have our cake and eat it too. We'll see.

Sounds like these discoverable PQSes aren't being cleared properly... I'll make an issue for it on my tracker and look into it. As long as it's not game breaking I still count myself victorious... lol

That is super weird. This is also a part of Kopernicus where honestly, I have no idea how it works or even what goes on (hence me knowing that it could not possibly have changed at all). Doesn't help much that In my personal game I haven't even went anomaly hunting, more like still trying to hit Duna. I'm much better at modding than flying space rockets, lol. Doesn't mean I won't look into it, but this one may take a bit. I wonder if it's related to all the weird scatters vanishing at a certain longitude-range bug that OhioBob mentioned? Maybe they are ending up at the poles for some odd reason? EDIT: Oh wait, nevermind found the post and that's just passive scatter landcontrol stuff that dissapears, doubt they'd appear on scanners. Just for clarity, you tried Prestja's 1.9.1, correct? I'd like to open the bug there but if it doesn't happen there, that might look silly. Also a log file from when this occurs (freshly after going to the site, ideally) would be great.

4kSP is your best bet, but certain mods will still be a pain. If that isn't enough, I would advise running in 1080p mode, as painful as that may be. It's a straight integer scaling ratio from 4K, so it shouldn't look worse than 1080p uh... normally does.

I haven't altered anything with Moho-templating. I did alter the Jool-templating code in a 1.10 forward thinking way: (it now basically builds a "non-newshader Jool" from scratch), but that definitely isn't messing with Moho. My mind wanders. Messing with Moho sounds like a Kerbal band,

There are at least a few odd things with EVE in modern builds of KSP @Waz is aware of, but doesn't really know how to fix. Or so that's how I remember it. I made a build that fixed rocket plumes blending into the sky badly, but this doesn't sound like that at all, so it won't help here.