R-T-B

The board is due to arrive tommorow, according to usps tracking. If that is in fact, fact, it'll take a day to get setup, but then we are back to full steam ahead.

Damn, z270 would be one I could work with... lol. Still, parts are already ordered, no sweat man.

Find the bugs so I have a hefty list when I get back, I guess? I'm also accepting (but not asking) for donations unofficially. If you can and want to contribute, pm me for a paypal link. I can't/won't ask for more than the motherboards $150 cost though, and remember, development continues at the same time regardless. For full disclosure, the total donation thus far has been $35 from one user. Up to him to identify himself, I can only confirm. If the above is against forum policy, mods can remove.

God, I know. All I can say is if this is the apocalypse, the vendors on hollywood "end of the world" flicks had faster and better quality service sometimes. Our world is just slow and boring. It might have been related but from the scorch marks I am pretty sure it was literally a stray screw. I engineer my computers like a kerbal, so not entirely impossible.

I'm not exactly enjoying it. Damn luck can be a killer some times. Plus my wallet was already light before this.

Bad news all. My primary work machine was victim of a stray screw somehow, working it's way lose and shorting out my entire system by letting out the magic smoke. Good news is I tested components in my brothers PC and only the motherboard seems destroyed. Bad news is sourcing a new motherboard during this pandemic is slow... so I'm probably going to be out coding wise for a good week at least (amazon shipping estimate). Yeah, never let the magic smoke out kids. It's what makes your PC work, and once it's out, it never goes back in. Which sucks. Plus it smells like toxic major bad stuff.

While always good advice, that shouldn't really be necessary for the CKAN release. We worked hard to ensure it is "safe" if not absolutely 100.00% bug free. You should be aware on any update "weird things" (tm) can occur, but nothing that'll corrupt your savegame or anything. We worked hard to ensure it's certainly very safe that way. Really the majority of bugs I have on my fix list are more convenience fixes for planet-pack authors, and end-users won't even care too much other than enjoying the work they will be able to do. At any rate, starting work on KittopiaTech at noon PST today. Wish me luck.

It was chosen in last release for 1.8. https://github.com/Kopernicus/Kopernicus/commit/c0b092e35eda0c83d3081ed5131c4c0503c3b4a9 Anyways, if this is a big deal I am not opposed to changing next release. The first CKAN already shipped this way though and that's unlikely to change because I don't have a time machine, heh. I was really just defering to "past authors wisdom" (or maybe lack thereof?) here. However, at the moment, I feel I am swayed by this argument: Change my view, I suppose.

The main stable release we just made is not ready for 1.10.1. The bleeding edge release, linked above, is. It's not as scary as it sounds, honestly. It works pretty well right now. It just lacks control of comets so it's not quite ready for prime time.

In hindsight, we probably should've put up more warnings about the changed solar code. I was overconfident that the few mods we shipped configs with were going to be enough, really. But I still maintain the default settings are still correct going forward. I probably WILL add documentation on how to disable the solar panels though for potential mod conflicts. Mind you, eventually other mods should adapt and adjust to this change and you won't need to think about this at all. We are just sort of in an ugly transition period with the code there, for the moment. I hope to not have to do things like this often, but there really was no other way to implement multistar that I could find, and yes I do believe multistar support is integral to Kopernicus and should be supported by default (with an opt out for chance bugs, of course). If I could do it all over, I probably would make the solar panel code turn on/offable in the Kopernicus_config.cfg file we now have that anyone can read/edit easily. But I was reusing some old code, and I tried not to rock the boat too much by using it's old module manager syntax. Guess that's where we are now, for better or for worse. Certainly doesn't make sense to change it yet again, now. I think the best thing to do for now would be to just update the release link with the information on how to disable this mode, which is really easy to do. I'll do that now. EDIT: Actually, only Prestja can do that, lol. Anyways, I tried. Maybe next release we'll ship that option as an optional extractable "extra" zip if it's still an issue.

I'm not opposed, but I just learned ModuleManager syntax and that is quite a bit outside my domain to implement.

We've discussed that internally and decided that since those lines are only there to enforce the behavior of the solar panel disabling parameter, to leave it alone (it was done originally by the Kopernicus devs who came before us, actually). Any modification to that property would lead to undefined behavior anyways, is my logic. Or am I misunderstanding? Since this is the second time that was suggested, I am open to changing it to a :LAST in next release. I'd just need good reasoning to do so, and I'm listening.

Yeah, in short this release is going to be hell on some mods that touch the solar panels. And yes it was changed in the middle of 1.9.1 development, so you could've had an old build without it. Unfortunately, though we did cause the breakage, we can't fix it in all cases (we shipped modulemanager configs when we could), it's up to mod authors to be aware of our changes if they can't be fixed with a ModuleManager config or something. We are more than willing to provide advice and code assistance to understanding what's going on of course, but we just can't edit other peoples projects for them. That'd be unmanageable and also possibly look like plagerism. The reasoning for this is proper multistar required a full hijakc of the solar panel subsystem, whereas before we used to use a new module called "SolarPanelFixer." SolarPanelFixer is no more, and KopernicusSolarPanels is now on it's own, handling everything. There really wasn't another way to override the method we needed, so it had to be done for multistar. If you are in a single star system, you can always turn off Kopernicus solar panels and likely fix issues like this, with a modulemanager patch, like this in a .cfg file in gamedata. @PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL { useKopernicusSolarPanels = False } This will turn off Kopernicus multistar panels and revert to stock panel behavior. PS: If someone could kindly point the author(s) of BackgroundResourceProcessing to this post, it'd probably help them.

I feel like I should be disturbed by this, but I'm just so happy your launch coincided directly with my "take a break from modding to really play KSP" three day vacation. Thank you. If the above story is true, please tell me where I can pitch in a tenner towards the new GPU fund, because I seriously would. I'd offer to pay for counseling too, but who am I kidding? I can't even afford the GPU.

No problem. Just a heads up that comet-related bugs are on the backburner for right now, while I work on getting Kittopiatech working. But comets work more or less in single star systems (all bugs with them relate to complex custom multistar) so I don't see it as a huge deal right now.

Just an update on Kopernicus teams plans moving forward. We are currently on the tail end of a three day break (for me at least) following our big release. After that, we have a big list todo, as always, but 1.10.1 is not at the top of it just yet. We have decided that that is functioning well enough in bleeding edge to be basically usable (if lacking some customization) and that the most important project going forward is KittopiaTech, which we will attempt to get working properly again. Planet pack authors really depend on KittopiaTech so it's semibroken/mostly broken state right now is really not ideal. After that, we may see about one bugfix release for 1.9.1, but that'd be the only release in the CKAN branch if it even happens (depends on whether or not big bugs get reported). Then, we start work on 1.10.x branch being CKAN-upgraded with full Jool shader and comet control. So that's our roadmap for probably, oh I'd say the next month. I have no idea when we'll reach each target within the roadmap, but will update when I start work. I suspect KittopiaTech is going to be the hardest part though, so it might take a few days or even a week just to get through step one. EDIT: Each roadmap step bolded for tl;dr types. For the immediate term, if you know of bugs while using KittopiaTech in 1.9.1 (not 1.10.x that is a separate target), please report them at my github fork here: https://github.com/R-T-B/KittopiaTech/issues

That's why I said "the old one" as in, the 1.7.3 release we are discussing that is listed on CKAN. I know about the recompiles/updates, but that's not what CKAN is indexing. Sorry for not making myself clear. EDIT: Oh, the footprints ARE good for 1.8? Interesting, thanks for letting us know!

It's pretty beta right now. Only two packages of the whole thing work. I'd say it's a manual download-grade at this point. The old one does not work past 1.7.3.

And he ran it by me first, so no one get on his case. I think this is a good thing and I welcome it. Shaders confuse me anyways!

Also, someone tell KopernicusExpansion that they do not work past 1.7, silly people.

Kopernicus has been submitted to CKAN. We are awaiting the bot grabbing it to index it. Here are the final release notes: New in this version (1.9.1-1) 1.) Particle support restored. 2.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1 3.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter. 4.) Stock asteroid generation enabled for SENTINEL contracts (can be shutdown for planetpacks or by user, see below) 5.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable stock asteroid generation. Easy to edit, just look inside! If you want it NOW and not later, you can grab what the bot will eventually index here: https://github.com/Kopernicus/Kopernicus/releases

Yeah, I really wish I knew an effective way to fix it...

Well, if you want to handle things yourselves, that's perfectly acceptable. Just override the Kopernicus solar panels in the part config as one always has. Still works.

If JNSQ didn't have the "farm patch" land bug right now (where some land tiles sometimes tile at slightly different colors due to pack compatability issues with the latest shaders), I'd probably be playing it now. It's a great pack, but that issue, though minor, just drives me crazy. I miss the icebergs having went to OPM, truth be told. Yes, you can practically RP that bug away by saying they ARE farm patches, but the inconcsistency in which it occurs still gets to me in my head... lol.

Kopernicus 1.9.1-1 CKAN Release Candidate Hotfix 4 R-T-B released this 13 seconds ago This release is a CKAN release candidate. It has been well tested in bleeding edge, and barring new bug reports, will probably be on CKAN in a few days. Besides the base features (listed below), it has the following small bugfixes: 1.) Fix for gas giant shadows-angle regression bug. 2.) Fix for Kopernicus panels failing to completely disable when requested to do so in some instances. 3.) Fixed doubled asteroid spawns when stock generator was enabled (it is by default). 4.) A fix for near future solar support/compatability. 5.) Fixed a texture path bug that caused slightly desaturated gas giants. That's all, it also has all the old new features, including: 1.) Particle support restored. 2.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1 3.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter. 4.) Stock asteroid generation enabled for Sentinel contracts (can be shutdown for planetpacks or by user, see below) 5.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable stock asteroid generation. Easy to edit, just look inside! Please replace the entire Kopernicus folder in this version, as it includes a new normal map (you should always do this anyways, and remember to reapply any config customizations). As this was a simple bugfix, I still see us as being on target for a Wednesday release (yep, that means tomororow!). Yes, bleeding edge got the same updates. Look for release 20, in that branch.